I feel configure events and requests are messed up

[Giovanni Campagna]

Il giorno mer, 14/09/2011 alle 10.37 -0700, Bill Spitzak ha scritto:
> 
> 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.

Nope. The only case for step 7 is when the client is animating the
resize. The client is expected to fully handle (as per the definition of
"handled" in the compositor flow) every configure_notify event, at some
point, otherwise it is just broken.
In any case, the client won't receive any other configure_notify event
(unless the user is moving the mouse): it is expected to setup its own
animation framework if it wishes so. Therefore even a misbehaving client
won't go in an infinite loop, and potentially the client can be held in
the "resizing" state (with a wrongly sized buffer) indefinitely.

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

I was thinking more of snapshotting window metadata (size, position,
state, etc.). You still need to have the buffers available, but you
don't need to copy them, just keep them mapped to your address space
(for shm) or bound to a EGLImage (for DRM).

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

Sorry, I just don't understand why you have to delay drawing until you
have processed all requests. Following your reasoning, a client could
stop the compositor from updating the screen by just sending
wl_surface.attach with the right timing (in current wayland, with no
resize related changes).

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

But you have to composite it on screen, and you have to draw all the
other compositor UI (which is pretty expensive, if you have Unity or
GNOME Shell).
Client-side decorations have no impact in this, there is still a time in
which the compositor is "busy drawing", and will delay incoming
requests. After all, we're designing for unlimited latency, right?

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

Uhm... Why?
The client creates the buffer, draws on it, attaches it, puts the buffer
apart. Then asynchronously receives wl_buffer.release and destroys the
buffer (or unlocks it, for future reuse).
I find it pretty simple, especially given that it's completely and
transparently handled by libEGL, so you don't really need to worry about
that.

On the other hand, the compositor must wait after drawing to release the
buffer, otherwise the client can reuse it or destroy it, and the
compositor would then draw garbage on screen.

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/20110916/e79dc53f/attachment.pgp>