[vtk-developers] window going blank...

David Cole david.cole at kitware.com
Tue Oct 7 10:32:25 EDT 2008


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> 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
> 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/5e3d40ac/attachment.html>


More information about the vtk-developers mailing list