[vtkusers] Multithreading

[Daniel Lüken]

Thanks.

Hmm... Looks a lot like my 3rd approach.

I found a way to do it without multithreading. The scheduling is not quite 
as nice as in my original threaded version, but it works. I changed the 
message loop a bit to make it look a bit more like the average message loop 
in games and added an observer pattern, where update routines could register 
themselves if they needed some input-independent calculation time:

// Modified message loop. The rest should be quite self-explanatory.
while(TRUE)
{
    if(PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
    {
        if(msg.message == WM_QUIT)
            break;
        if(!TranslateMDISysAccel(hwndClient, &msg))
        {
            TranslateMessage(&msg);
            DispatchMessage(&msg);
        }
        if(m_settings->getForceFluentInteraction()) // Skip the calculations 
when there was a message to process. This won't make much of a difference 
for a single event, but a huge difference in a series of continuous events 
like dragging the mouse in an interactive renderwindow.
            continue;
    }
    // CPU time needed?
    if(m_appUpdateListeners->size()) // Yes => Notify observers to make them 
do some calculations
        appUpdate();
    else // No => Give up the CPU time, because user input is required to 
activate the render process.
        WaitMessage();
}


----- Original Message ----- 
From: "Beau Sapach" <beau.sapach at ualberta.ca>
To: "'Daniel Lüken'" <d.lueken at stud.fh-dortmund.de>; <vtkusers at vtk.org>
Sent: Tuesday, May 08, 2007 7:01 PM
Subject: RE: [vtkusers] Multithreading


I've seen it posted before, "Never call Render() across threads." Or
something like that...

I haven't had much luck with this sort of scenario myself but I chalk that
up to my lack of knowledge with threads.

One approach (although I haven't tried this myself) might be to have an
entire rendering pipeline created on a "worker" thread, which would render
RGBA pixel data off-screen.  This pixel data could then be passed to a
render window on the main thread (or possibly any other thread).  I believe
once you have RGBA data the CPU intensive work is done.

Beau

-----Original Message-----
From: vtkusers-bounces+beau.sapach=ualberta.ca at vtk.org
[mailto:vtkusers-bounces+beau.sapach=ualberta.ca at vtk.org] On Behalf Of
Daniel Lüken
Sent: Tuesday, May 08, 2007 10:45 AM
To: vtkusers at vtk.org
Subject: [vtkusers] Multithreading

Hello,

I'm using VTK 5 statically linked into a C++ Win32 application.

My problem is, that I can't get it to work across multiple threads. There's
always just 1 thread working with a vtkRenderWindow, so general
thread-safety shouldn't be a problem. (If I'm not mistaken, there's even
just 1 thread working with any vtk function at any given time.)
My first attempt was to create and destroy my vtk rendering environments in
the main thread and handle new incoming data in another thread, which called

Render() after updating the data and performing the necessary operations.
(Which would just be updating the debug text in a vtkTextActor as of yet.)
That attempt failed on the Render() call, stating that wglMakeCurrent()
failed.
My 2nd attempt was to replace the Render() call with an InvalidateRect()
call on the window containing the render context, but then another vtk
render window didn't react anymore, except if I added a Sleep(1) after
InvalidateRect() (I wonder why that seems to work. Sleep(0) won't and the
reaction doesn't slow down compared to a Sleep(5000)).
My 3rd attempt was to put the initialization and deletion of the vtk
rendering environments for my visualization windows into the thread that
handles the updates of newly incoming data, which resulted in a sudden halt
of the main thread, even though I didn't use any kind of locks.

I will have to update my data in another thread, because it constantly has
to check for new input and update the visualizations, which would keep my
main thread from returning to the message loop, which is kind of
undesirable.

Any ideas?

D. Lüken

_______________________________________________
This is the private VTK discussion list.
Please keep messages on-topic. Check the FAQ at:
http://www.vtk.org/Wiki/VTK_FAQ
Follow this link to subscribe/unsubscribe:
http://www.vtk.org/mailman/listinfo/vtkusers