I feel configure events and requests are messed up

[Giovanni Campagna]

Il giorno ven, 09/09/2011 alle 10.55 -0700, Bill Spitzak ha scritto:
> Giovanni Campagna wrote:
> 
> > Anyway, I'm not convinced that client-side decorations are technically
> > superior, therefore I'll start a new thread, to have a final discussion
> > with all interested parties. Mutter makes some deep assumptions on
> > framing, for sizing policies and for event handling, and I'd like to
> > clear them out before going further.
> 
> I see no way the interior and borders can draw cleanly and synchronously 
> without client-side drawing of them.
> 
> You need to describe the exact steps by which the client and compositor 
> can cooperate so that at every single moment the compositor is able to 
> either put the old contents+border on the screen, or the new 
> contents+border on the screen. Any solution must allow for unlimited 
> latency in communication between client and compositor, and unlimited 
> latency in either process between receipt and sending a message. Any 
> such solution must also not involve otherwise unnecessary copying of 
> images, or require the client or compositor to preserve a possibly 
> unlimited number of image buffers. It would also be nice if clients 
> could throw away the old image as soon as they have drawn the new one, 
> but I don't think it will be possible so I'll let you have that one.

In the client:
1) You receive a configure event reporting your new expected size. This
event has a serial number.
2) You allocate a buffer of a valid size (between the previously
attached size and the new size)
3) You draw on that buffer
4) If the buffer was not new, you request wl_buffer.damage as needed
5) You attach the new buffer, including in you request the serial of the
configure event, if the size matches, or 0 if not.
6) You emit a sequence of wl_surface.damage as needed.
7) If the newly attached size is not equal to the received size, you
asynchronously goto step 2.
-or-
1) You receive a toolkit command requesting a new size.
2) You emit a configure request.
3) You wait (asynchronously, acting if nothing has happened until you
see the message) for a configure event.
4) You can now follow the other code path.

In the compositor:
1) You receive a damage request for a wl_surface
2) You acquire the complete client buffer (from the latest attached
wl_buffer)
3) You compute the window size: if the client is currently resizing, and
the buffer size is within the previous buffer size and the size of the
latest configure event, or the attach request had a serial that
corresponded to one of the configure events still in queue (and the size
is equal to the configure event's size), the buffer size is OK,
otherwise it is clamped. When it matches one of the events in the queue,
it clears all events emitted previously. Width and height are treated
individually by these computations.
If the client is not resizing, size is always clamped to latest emitted
configure event.
(Client is marked resizing when a configure event is emitted, and marked
not resizing when the queue of configure events is empty)
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

The compositor has to remember the most recently attached client buffer
for each wl_surface, and a series of unhandled configure events. Since
we're allowing for unlimited latency, you'll allow me to make this queue
unlimited (it is asymptotically the same size as the socket buffer); in
reality, this queue will have a reasonable maximum size and clients
lagging will be marked as such (with an option for the user to kill
them).
In point 3 of compositor path, the size is guaranteed to be the
wl_buffer.size, unless the client is misbehaving; this is true both for
client-side animated resizing (a single configure event and a series of
buffers of interpolated sizes) and for compositor-driven user resizing
(a series of configure events; the client can ignore some configure
events or process them all; the compositor will always wait for a buffer
of the appropriate size matching the latest configure event, and draw
whatever it has in between).
Clients can be mistakenly marked "resizing" even if they have not
received the configure event, but since the previous buffer size is
always a good buffer size, they can go on happily drawing until the get
it. Clients won't be marked "not resizing" until they attach a buffer
with the serial of what the compositor thinks is the latest configure
event (which is greater-or-equal to what the client thinks is the
latest).

This is very similar to current wayland, except for the addition of the
configure request and configure serials, that restrict the set of valid
sizes to what the compositor likes.
The serials in particular are for cases when the compositor emits
(100,100), (200,200), (100,100), and he cannot know if a buffer sized
(100,100) is for the first event (client processing in order, or high
latency) or the last event (client processing out of order, with low
latency), which in turns means the compositor cannot know if (200,200)
will ever be a good size.

> If this cannot be proven to work then Wayland will look like the same 
> crap that X11 looks like. Broken update of resize and drag has been true 
> for 22 years now, despite the machines increasing in speed by about 500x 
> during that period of time, showing that this is not solvable by "speed" 
> and is entirely due to the async nature of two processes trying to draw.
> 
> My other complaint is that everybody arguing for server-side decorations 
> for "consistency" somehow don't seem concerned about "consistency" of 
> buttons and scrollbars and menus and all the other stuff that X11 window 
> managers do not do. And they seem to ignore the rather successful 
> methods of making all the toolkits consistent without having everything 
> drawn by the same process.

In fact, they're not consistent at all. Just look at Qt having to pull
Gtk just to have a decent theme under GNOME. Not to mention Athena or
Lesstif...
(and then you have inconsistencies even within the same
community/toolkit, for example when apps force icons in buttons or don't
add the primary_toolbar style class).
So no, having consistency handled by toolkits won't work, in particular
when they are cross-platform and cross-desktop, with different
environments (like GNOME and Xfce) having different designs and
requirements.
In any case, I'm not entirely sold to server-side decorations, and I'll
accept csd if this is the consensus within the various involved
communities (not that I can do otherwise, anyway :) ) Just I don't see
much advantage of it, while I see clear disadvantages.

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/20110911/30286bf5/attachment.pgp>