I feel configure events and requests are messed up

[Bill Spitzak]

There seems to be some confusion between negotiating the correct size 
and the drawing of the frame. These are unrelated.

I mostly agree with your ideas of negotiating the size with both a 
request from the client->compositor as well as the other way, except 
there must not be any "looping". The client is not going to magically 
start chooosing the "right" size just because the compositor sends an 
infinite stream of configure-notify calls.

The main problem with your design for separate client+compositor drawing 
of the decorations is right here in your description of the compositor:

> 4) Using current window state, current window position and computed
> window size, you draw the frame
> 5) You draw the client buffer on top of the frame. Since the frame was
> sized using on the client buffer, everything but the actual border is
> covered (or partially so, if the buffer is transparent)
> 6) You swap the buffers, and the screen is atomically updated

This is a potentially unlimited delay of the swap, since any of the 
clients at any time can resize, and you cannot swap until the new frames 
are drawn, during which time even more resizes can happen. You are also 
assuming that the compositor copies into a screen buffer, rather than 
generating the composited image on the fly as the screen is redrawn.

The only way to fix this is to preserve the old buffers for both the 
client's contents and the old frame. They can only be thrown away after 
the frame is fully drawn, by the compositor sending a message to the 
client indicating that it should do so. This would require a potentially 
unlimited number of old buffers to be preserved by the client. Or the 
client will have to ignore configure notify calls until the old buffer 
is thrown away from the last one it responded to.