I feel configure events and requests are messed up

[Kristian Høgsberg]

On Tue, Sep 6, 2011 at 6:39 PM, Giovanni Campagna
<scampa.giovanni at gmail.com> wrote:
> Il giorno mar, 06/09/2011 alle 15.27 -0700, Bill Spitzak ha scritto:
>> Giovanni Campagna wrote:
>>
>> > You can do instantaneous updates even if the size is determined by the
>> > compositor, rather than the client: you just wait for the client to
>> > prepare a new buffer before redrawing the window.
>>
>> The compositor would have to somehow be prepared for the client to
>> *never* produce the correct image. What you describe is in fact exactly
>> the same as what Wayland appears to be doing now, except what you call
>> the "The client has prepared the new buffer" is what I am calling the
>> "resize call".
>
> Uhm... I see what you mean, but read below.
>
>> > Except that if the new buffer is not appropriately sized, you clip it
>> > or transparently extend it to the new size.
>>
>> Actually I think this can be done by a wayland compositior right now. It
>> can draw anything it wants, and can thus clip the source buffers or add
>> rectangles of other graphics around them. So a tiled window manager will
>> always show touching and non-overlapping tiles, which I think is your
>> concern.
>
> No, my concern was maintaining consistent client and server state. Plus
> it is a different approach.
> On the one hand, you have a stale buffer, which will be updated as soon
> as possible by libEGL (transparently to the application), and all other
> client state (GDK, cairo, Cogl) reflects the server vision; plus events
> outside the server mandated boundary are not generated. Effectively no
> application code is involved, everything is handled by the toolkits.

I assume you're describing how X works here?  The "transparently" and
"as soon as possible" updating of EGL (or GLX) buffers is the core of
the problem and one of the main reasons Wayland resizing works as it
does.  Resizing GLX or EGL windows under X is a sad mess and there is
no concensus on window size.  At any given time during resizing, the
toolkit tries to render a frame at a certain size, but there's no
knowing what size the GL buffers are (depends on how many DRI2 events
the stack has seen since the toolkit decided to resize) and the X
server could have changed the window size in the mean time as well.
The only thing you know for sure is that "eventually" the resizing
will stop, there will be one last ConfigureNotify, the toolkit will
update its size, EGL will have reallocated the buffers at that final
size, and when you finally do eglSwapBuffers, the X window still has
the size that the ConfigureNotify gave you.  But that's the very last
frame in the interactive resizing, everything in between is a wash.

WIth Wayland, the compositor tells the client "please be this size"
(the wl_shell configure event), which will be handled by the toolkit,
which will tell EGL the new size of the surface (so we know EGL and
the toolkit agree on the size) and then at swapbuffer time, EGL will
send the new buffer to the compositor which will use the size of the
buffer as the new window size.  There's newer any uncertainty of the
size of the GL buffer you're rendering to, and the swapbuffer isn't
going to get clipped because the server changed window size in the
meantime.  It's simple and predictable and every pixel is perfect.
Exactly as in the X case, no application code is involved it's all
handled by the toolkit.

> On the other hand, you have compositors sending out hints for user
> actions, but effectively resizing if and when the client (application
> level code) wishes so. Heck, at this point a client could map a
> fullscreen window and make it unresizable, irrespective of the
> limitations a compositor makes on fullscreening.

You have the same, if not more options for controlling how clients
windows appear under Wayland.  The clients just pass their buffers at
the size they want to be (which is typically controlled by the
compositor sending out wl_shell.configure) and the compositor can do
whatever, clip or pad the buffer to be a different size.

>> I still feel a client may have a better idea how to pad it's own
>> information, so I think resize requests need some indicator as to which
>> edges are really wanted by the compositor to not move. However if a
>> client disobeys this the compositor can still restrict the resulting size.
>
> I understand what you mean, in fact I talked about gravities in my first
> email, except that this model (passing edges to clients and expecting it
> to compute the correct position from that) puts it not only in control
> of size but also of position, which is completely broken.
> A client should never be able to move it's own window, unless the
> compositor can be sure it's a result of user input. In fact, Mutter
> rejects most of ConfigureRequest that specify a position and
> consistently ignores the original position upon mapping.

The x and y passed in the attach request specifies the position of the
top-left corner of the new buffer relative to the top left-corner of
the old buffer.  It's not an absolute screen position.  It's necessary
both for interactive positioning and when window change size
spontanously.  For resizing, if you're resizing a window with size
constraints (aspect ratio or character cells), the client needs to
tell the compositor where the window should be positioned relative to
the old one.  Similarly, if you're animating a window growing
(expanding dialog or a side pane sliding out from the left side of a
window), you need to provide relative offsets of the window position
as the pane slides out on the right side of the window.

Kristian