[cairo] XDBE

[Bill Spitzak]

Soeren Sandmann wrote:

> The protocol that gtk+ and metacity use, which is documented in the
> cvs version of the freedesktop wm spec, does not in fact eliminate all
> distracting intermediate drawing. What it does is more limited:
> 
> Every time the window manager resizes the frame, it also sends a
> message to the application "Here is a number n -- a ConfigureNotify
> will follow very shortly. When you have handled all associated
> repainting, please send the number back to me." The window manager
> then waits for the reply before doing the next resize (metacity has a
> timeout of 1s so that stuck applications can still have their windows
> resized).

Not really thrilled with this. A far simpler thing would be:

1. Window manager sends a message saying what it wants done (ie size, 
shape, what edges are being moved, and whether to raise the window). It 
does not do anything else.

2. Program then responds by doing whatever it wants, such as choosing 
it's own size, raising other windows, etc. It then does that using 
normal calls.

3. Window manager sees these requests and obeys them.

4. Window manager can do a timeout and force a window to move/resize if 
the program appears to not be responding.

Trying programs that allow the user to resize it by dragging a corner 
inside the window, it is apparent that if the program does the resizes 
most or all of the flickering of X can be eliminated.

An even better scheme would be for the application to be required to 
resize the parent "frame" and it's own window. This would allow 
completely synchronous resize and redraw of the contents. The window 
manager would no longer override-redirect. It would instead have to 
asynchronously redraw the window frame, but because it is likely to be 
swapped in, and the drawing is simpler, this should be much less of an 
issue that the async contents are now.