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.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
