Kevin Altis wrote:
In the PythonCard life and hopalong samples I am calling wxSafeYield and the screen updates as expected on the Mac, so I'm guessing this is one of those cases where you need to do the same?!
This points to the issue being event related, but wx.Window.Update() is supposed to solve exactly this problem. From the docs:
"""
wxWindow::Update
virtual void Update()
Calling this method immediately repaints the invalidated area of the window while this would usually only happen when the flow of control returns to the event loop. Notice that this function doesn't refresh the window and does nothing if the window hadn't been already repainted. Use Refresh first if you want to immediately redraw the window unconditionally.
"""
Maybe I'll try Refresh() but I think there is a performance penalty to that. And I think that calls a Paint event, which could cause problems here too.
Calling a wx.SafeYield() has performance issues too....
Kevin Ollivier wrote:
Wow, that's really strange. Update explicitly calls QDFlushPortBuffer, which should force your drawing to the screen...
Maybe it's a bug then...
It's mostly a performance issue. Apple's docs explicitly say not to flush the port buffer after each drawing call.
well, I'm doing the double buffering myself, and not even using a wxBufferedDC, because I want to control what the users see. In the example I'm talking about, the screen is changing rapidly, It has to be updated rapidly. Another example is when I'm drawing 1000s of objects to the screen. This can take a little while, and I'd rather the user not sit there wondering if something is happening, so I do a blit every 500 objects or so, so they can see the screen getting drawn.
> The docs basically say to
> wait for drawing events to fire, which in my experience hasn't caused
> problems.
What are these drawing events? I tried something, and was surprised by the result. It takes a few seconds for all the frames to be shown (and nothing is changing on screen). If I click on another window, my window goes behind it. If I click back on my Window, it won't come to the top until it's done with the animation loop. This means that the system is telling my app to raise itself, and it's not procesing that evetn till it's done with the loop it's doing. This points to a need for Yield().
OK, I've tried it, and wx.GetApp.Yield(True) works. It does impact performance, but by 0.0025 seconds per Blit(), so I can't complain. In fact, generally during an animation, I'd want the Yield() there anyway.
-Chris
···
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
