[vtk-developers] window going blank...

[David Cole]

If you want to do something that takes longer than Windows' definition of
"not responding" and still call yourself an interactive Windows application,
at a minimum you need to call PeekMessage every few seconds (even if your
call does not remove the messages from the queue or process them...).

According to the documentation for the IsHungAppWindow Windows SDK
function...:
http://msdn.microsoft.com/en-us/library/ms633526(VS.85).aspx

...calling PeekMessage every 5 seconds should prevent the "not responding"
status.

It also says that 5 seconds is subject to change, and I would guess it's
less than 5 now with Vista.

It should be safe to call PeekMessage quite frequently. I would recommend
calling it within some portion of your pipeline that is guaranteed to be
called at least every second. Or sprinkling it throughout your pipeline if
necessary to get the frequency of call needed.


On Tue, Oct 7, 2008 at 11:33 AM, Lisa Avila <lisa.avila at kitware.com> wrote:

>
> 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
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20081007/93d6696f/attachment.html>