I feel configure events and requests are messed up

[Bill Spitzak]

Giovanni Campagna wrote:
> 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.

Your description of "in the client" has a step 7 that says "if the newly 
attached size is not equal to the received size asynchronously goto step 
2". This seems to imply that if the client disobeys the received size 
and uses another, it is required to somehow listen for another request 
(which it will just as likely disobey). This is an infinite loop.

The size the client chooses must be final.

> Or you can take a snapshot of the current window sizes,

"Snapshot of the current window sizes" means "copy the buffer to the 
compositor's own memory". I am under the impression that this is 
absolutely against Wayland's design criteria. There should be no copying.

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

The eglSwapBuffers will have to be delayed until *all* frames are drawn. 
Either it will be delayed a potentially unlimited time if clients keep 
sending new resizes, or the compositor will have to queue up and ignore 
pending resizes, drawing the old buffers and old frames for those 
windows. This sounds really complicated.

With client-side decorations the frame is already drawn before the 
resize notify comes in so the window is ready to display immediately.

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

I was under the impression that is a low-level sync protocol, expected 
to be echoed before the next event. If the compositor is allowed to 
delay it until some graphics are drawn then it becomes a lot more 
complicated for clients.