spitzak at d2.com
Tue Nov 22 21:05:26 PST 2005
Jim Gettys wrote:
> Would someone be so kind as to verify if this bug still exists, and,
> if so, get it into the X.org bugzilla?
Actually I remember this better, now. In fact this is an unavoidable
artifact of the seperate asynchronous window manager. What happens is:
1. program draws some stuff into the back buffer.
2. window manager resiszes the window, which resizes the back buffer
3. program possibly draws a bit more into back buffer
4. program sends XdbeSwapBuffers
At the moment the window manager resizes the back buffer, it is cleared
to garbage. But the program has no way of knowing this and thus swaps
the garbage buffer to it's screen.
A work-around is to make a single child window and use XDBE on that.
Then the window manager only resizes the parent, and the back buffer
remains unchanged because it remains the size of the child window
(apparently the back buffer area is not reallocated to the visible area,
which is fortunate...). If the resize happens in the middle of the
drawing, the SwapBuffers will put the previous size image on the screen,
which is not objectionable. When it gets the ConfigureNotify it can then
resize the child window and draw everything in perfect sync. It has
nothing to do with speed or avoiding XFlush.
I would like to see a better workaround, something I would call
"synchronous window management". What would happen is a program would
tell the WM that it understands this WM protocol. Then if the window
manager wants to resize, move, raise, lower, iconize, etc any window, it
does not actually do it, but instead it sends the program a message. The
program can then do whatever it wants, though it probably should do the
requested action. This idea would also get rid of a major reason X looks
"slow", and would allow arbitraryily complex rules about what possible
sizes and window stacking a program implements.
More information about the cairo