I feel configure events and requests are messed up

[Giovanni Campagna]

Il giorno lun, 12/09/2011 alle 13.18 -0700, Bill Spitzak ha scritto:
> 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.

I don't follow you here. The client will eventually pick the size the
compositor asked, because that's the protocol. The compositor only sends
one configure_notify, per each mouse motion / key press / configure
request / whatever. So if you get two configure_notify in a row, either
you made two configure requests, or they have different values.

> 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.

Or you can take a snapshot of the current window sizes, draw everything,
call eglSwapBuffers, go back to the main loop, notice that you have
other wl_surface.attach request that you need to process, update your
internal state, go to the beginning of algorithm.
With this, each buffer will be eventually drawn, at least once and at
least for one frame, and you don't need to think about other
wl_surface.attach requests until you go back to mainloop. Btw, this is
no different than a client calling eglSwapBuffers (thus updating its
surface) while the compositor is in the middle of drawing.
In any case, yes, I'm assuming the compositor will use GL to draw the
final image on screen, so it will draw to the back buffer and then
atomically update the screen.

> 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.

This already true in current wayland: buffers can be dropped only upon
the receipt of wl_buffer.retire. I don't know if there is something we
can do here, once you accept infinite latency in the server.

Giovanni
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 316 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20110914/cb898531/attachment.pgp>