[vtk-developers] window going blank...

[Lisa Avila]

The question is - is there any way to stop Windows from thinking the 
application is "not responding". This is an easy example to convert 
because we are looping over doing a lot of fast things. But what if each 
iteration of the loop takes 10 seconds - a really complex filter 
pipeline applied to large data for example. One Update path through the 
filter pipeline might take minutes - does that always need to be done in 
a background thread to keep Windows from complaining?

Lisa


David Cole wrote:
> The problem is that you are not processing/dispatching any Windows 
> messages in your tight loop, you are just rendering over and over 
> again. Windows sees an application that is not processing any messages 
> as "not responding"... Vista is more sensitive to it because end users 
> keep getting more demanding.
>
> A better way to achieve nearly the same result would be to set up a 
> repeating timer that does one iteration of your animation each time it 
> fires and then call Start on the render window interactor to start up 
> a message loop, thereby processing timer messages.
>
> If you decide in your timer callback that you are done and want to pop 
> out of the message loop, simply call ExitCallback on the interactor. 
> (See TestInteractorTimers.cxx for an example of quitting from a timer.)
>
>
> HTH,
> David
>
>
> On Fri, Sep 26, 2008 at 5:15 PM, Lisa Avila <lisa.avila at kitware.com 
> <mailto:lisa.avila at kitware.com>> wrote:
>
>
>     One other clue that this is Windows related - the top bar of the
>     window does change to "Not Responding..." when this blanking occurs.
>
>     So my best guess is that something causes a message to go to the
>     process (some random thing popping up, getting focus, or changing
>     on the screen) and if the process does not respond in a set amount
>     of time then Windows stops bothering to display the contents of
>     that process' windows. Any Windows experts out there know what it
>     is we have to respond to? We can throw in a timer event and check
>     the queue every so often (assuming we have some ability to view
>     the queue and not just blindly process it), but we can't really
>     process messages off this cue (other than WM_ERASEBKGRND because
>     we don't actually do anything but return TRUE on that one). I
>     don't know if we can selectively pull messages off the cue or if
>     we have to process all of them. I suppose we can go into a "don't
>     really process mode" and save the queue of events into our own
>     queue to process later...
>
>     Still looking for ideas....  :-)
>
>     Lisa
>
>
>
>     Lisa Avila wrote:
>
>
>         I have a nice brand new desktop with 64 bit Vista. An issue
>         that has been a minor problem for years is now more of a major
>         problem. Here is the basic concept:
>
>         set up a pipeline to view the first image in an animation series
>
>         while ( !done )
>          {
>          change the reader input to the next image
>          renWin->Render();
>          }
>
>         Previously on my 32bit XP system this worked for a while
>         (where "a while" was something on the order of a minute).
>         After that the window would just go to white or black, and
>         would return only after the animation was done. Now on my 64
>         bit Vista machine, "a while" has become much shorter
>         (sometimes just a second or two). In either case, if you cause
>         another window to be active, or anything else pops up on the
>         screen (like those little alert bubbles that pop up from the
>         bottom bar) then you immediately lose the image. Perhaps the
>         difference is that more of that is now happening in Vista and
>         that is why I often only get a second or two of rendering
>         before losing the image (although occasionally I will get 10
>         seconds or more...)
>
>         Is there a way to fix this? It should be valid to render in a
>         loop and expect to see the results indefinitely, right? Or is
>         that just not possible any more from raw C++ on Windows?
>
>         Sebastien sent me a link to
>         http://www.opengl.org/pipeline/article/vol003_7/ which has
>         some of the pitfalls that might cause this - but I can't see
>         anything we are doing in my simple example that would case
>         this (there is no intermixed GDI which I think we only use for
>         some instances of off screen rendering, we do return TRUE for
>         WM_ERASEBKGRND, etc.)
>
>         Any ideas?
>
>         Lisa
>
>
>     _______________________________________________
>     vtk-developers mailing list
>     vtk-developers at vtk.org <mailto:vtk-developers at vtk.org>
>     http://www.vtk.org/mailman/listinfo/vtk-developers
>
>