Am 30.12.2010 22:49, schrieb Ingo Weinhold:
On 2010-12-30 at 22:12:12 [+0100], Stephan Assmus<superstippi@xxxxxx> wrote:All these tips apply to BeOS. On Haiku, drawing is usually double bufferd. IIRC, even letting the app_server draw the background would not normally result in flicker, except if the draw request was caused by an expose event (i.e. one window moving or disappearing which results in another window to be exposed).Interesting. I knew about the double buffering, but I didn't think it was that aggressive. Am I assuming correctly that the back buffer regions are only marked clean (and copied to the front buffer) after the respective view's Draw() returned? That would also explain #5469, I guess.
I don't remember all the details. Resizing a window is definitely an expose event and is treated differently than a client initiated invalidation. However, the effects might still be explained by the back to front copying behavior. I think the idea behind how it works is sane, and the misbehavior observed could be fixed without changing how double buffering and delayed copying to the front buffer works. Also, the app_server maintains two redraw sessions, a currently active one and the next one, in which subsequent invalidations pile up until the current session is finished. IIRC, there are situations in which parts of the current update session are clipped by invalidations in the next update session. This may be the problem, but I also have a faint memory of having disabled this code.
Best regards, -Stephan