[vtk-developers] window going blank...
Lisa Avila
lisa.avila at kitware.com
Tue Oct 7 12:28:09 EDT 2008
Thanks! That's what I was looking for. :-)
Lisa
David Cole wrote:
> 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
> <http://msdn.microsoft.com/en-us/library/ms633526%28VS.85%29.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
> <mailto: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>
> <mailto: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>
> <mailto:vtk-developers at vtk.org <mailto:vtk-developers at vtk.org>>
>
> http://www.vtk.org/mailman/listinfo/vtk-developers
>
>
>
More information about the vtk-developers
mailing list