I feel configure events and requests are messed up

Wed Sep 7 03:54:52 PDT 2011

Il giorno mar, 06/09/2011 alle 23.30 -0400, Kristian Høgsberg ha
scritto:
> 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.

Yes, X11 works like that and is messed up because you have core events,
GLX events and DRI events. On the other hand, if you introduce one
configure event in wayland, you can expect that toolkits will start
drawing the new frame only at the receipt of it, at which point libEGL
has received it as well and the buffer has been resized (or actually,
recreated). Then the toolkit draws on it (not synchronously when seeing
the event, but at the next master clock tick) and finally it calls
eglSwapBuffer, replacing the old buffer at the old size with a new
buffer at the new size, at which point the compositor updates the
window.
In particular, at no point there is application code involved, and after
the receipt of the configure event all of gdk_window_get_size,
cogl_onscreen_get_size, eglQuerySurface (and the upper layers, like
gtk_window_get_size and clutter_stage_get_size) report the same size,
without using intermediate synchronization between them. Which brings us
to my second goal: killing all middle-level toolkits and glue code (like
libwayland-egl) and make sure that libwayland-client has all the
necessary to integrate multiple toolkits.

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

No. In libtoytoolkit (my reference for clients in this discussion), you
have a hook that decides the size of the surface, and it can potentially
return anything, or just ignore the configure event altogether.
I can accept having a separate get_width vs get_attached_width, both in
the client and in the compositor, and using the second one for redraws,
but eventually (read: before the next vblank) the second must become
equal to the first. Otherwise I consider the compositor free to clip or
pad with decorations.

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

Exactly. Clients should not have this level of control of window sizes.
Sizing a window is a matter of policy, and the compositor should be in
absolute control of window sizes.
Application level code should not be able to mandate how big the window
will result, and the only way to change the size of a wl_buffer should
be as a result of a configure event from the compositor (which means
that clients ignoring the compositor will be clipped client-side, and
server side clipping will only happen if the client is lagging). EGL
should update itself independently of any other toolkit or application
code and only obey the compositor.

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

I know it is a relative window position, but it is enough for the client
to position itself wherever it wants (since it can specify any delta),
thus it allows the clients to conflict with the compositor's idea of
window position.
And again, this fact the final window size is the size of the latest
attached buffer, rather than being an explicit request on wl_surface, is
completely broken to me. Clients wanting to change the window size
programmatically (for example because a new widget is shown) may need to
specify which reference points should be fixed (and nothing else) -
that's why you need a configure request; on the other hand, if the
compositor is resizing the window as a result of user actions, it knows
already what should be the new position.

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/20110907/9328705a/attachment.pgp>