[cairo] XDBE

[Bill Spitzak]

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.