I feel configure events and requests are messed up

Thu Sep 8 14:14:54 PDT 2011

Il giorno gio, 08/09/2011 alle 16.32 -0400, Kristian Høgsberg ha
scritto:
> 2011/9/8 Giovanni Campagna <scampa.giovanni at gmail.com>:
>>[...]
>>
> > I have nothing
> > against having GDK calling wl_egl_window_resize,
> > cairo_gl_surface_set_size, cogl_onscreen_update_size, etc. as part of
> > interactive resizing, and I have nothing against the compositor
> > accepting any buffer in that time. But outside of that, I want
> > applications to respect the given size.
> > It's like a widget system: from a widget implementation, you can ask a
> > bigger size, but you cannot actually draw at the new size until you're
> > allocated again, and you have no guarantee that you'll be actually given
> > the preferred size.
> 
> Ah, but you *can* actually draw before you get the size.  The idea is
> also to reduce roundtrips between the compositor and client.  The
> client isn't messing up anything for anybody else by assuming it will
> be allowed to resize and drawing at the new size.  And there is really
> no point in asking the compositor "can I be this size" and then
> waiting for "yes you can" before drawing.  We can just resize and draw
> at the size we want and present the end result to the compositor.  We
> should probably add an event for the case when the compositor rejects
> the new size, but there's really no need to add a
> configure_request/configure_notify roundtrip when pretty much all apps
> will behave well and resize to a size that will accepted by the
> compositor.

Is this assumption really so safe?
Mutter for example has a whole file of 1510 lines
(src/core/constraints.c in current master), dedicated to constraining
positions and sizes of windows. Some of the constraints there are
positioning only, or don't apply to current wayland design (like the
size increments and size limits), but those related to keeping a window
completely within the workarea, or keeping it maximized/edge-tiled,
clearly have their say.
And by the way, wayland it is by design local-only. An async 24 bytes
message (4 int32_t + the header) is almost free to send on a unix
socket.

(Btw, I'm happy that we finally clarified the misunderstanding between
what I wanted to achieve and what you wanted to preserve)

> >>>[...]
> >> >
> >> > And that's my problem with it: toolkits needs to be mixed. I'm not
> >> > saying mixing Qt and GDK (although Qt wants to load Gtk to render GNOME
> >> > themes...), but of GDK, Cairo and Cogl. You don't want Cairo to depend
> >> > on Gdk or Cogl (one of the maintainers already told me that this is not
> >> > acceptable, as Cairo wants the maximum portability),
> >>
> >> Did you notice cairo_xlib_surface_set_size()?  Cairo doesn't magically
> >> listen for X events and resizes the cairo surface behind the toolkits
> >> back.  Cairo works the same way.
> >
> > True, but the only place that wants to call
> > cairo_xlib_surface_set_size() is Gdk (or whoever created the surface in
> > the first place). Bad things happen if application code invokes it, and
> > I consider it cleaner if we can prevent it from the very beginning, by
> > not having a cairo_wayland_surface_set_size().
> 
> It's already there, it's cairo_gl_surface_set_size().  And why do you
> think wl_egl_surface_resize() is different from
> cairo_xlib_surface_set_size() in terms of who calls it?  If you're
> using cairo-gl, that will call wl_egl_surface_resize(), if you're
> using clutter, cogl will call wl_egl_surface_resize().  It's not an
> application level API.

True, but wl_egl_surface_resize()/cairo_gl_surface_set_size() have a
visible effect, cairo_xlib_surface_set_size() hasn't (you need
XMoveResizeWindow if you want it). But anyway, we can probably agree
that applications going down to cairo-gl and wayland-egl are broken
anyway and they should instead use a toolkit, so I'll stop worrying
about them much.

>>> [...]
> >>
> >> We don't want the EGL buffers to match the latest size from the
> >> server, we want them to match the size that the client saw when it
> >> scheduled its redraw.  Wayland resizing is designed so that there's
> >> one predictable flow or pipeline of resize events instead of hitting
> >> different parts of the stack with different resize events at different
> >> times:  The new size comes from the compositor (in case of interactive
> >> resizing) or the clients animation framework (in case of animated
> >> resizing).  The toolkit receives that size and relayouts widgets and
> >> schedules a redraw.  The redraw triggers and tells the rendering
> >> library what size we want the surface to be, renders the frame and
> >> then finally presents the frame to the compositor, which atomically
> >> updates the contents, size and position of the surface.
> >
> > You don't want EGL buffers to match the size when the client scheduled
> > the redraw, you want them to match the size that will be drawn on the
> > screen.
> 
> Sure, but then when you start drawing, GL will do a roundtrip behind
> your back and get a different size anyway.  Rendering APIs that change
> the surface size autonomously and unpredictable behind your back are
> broken.

GLX/EGL-x11 does that roundtrip, EGL-wayland would not, it would use the
latest received configure_notify event, which by the time the app starts
drawing has been already processed by the toolkit. But yes, libEGL
having an handler for configure_notify, or GDK calling
wl_egl_window_resize as the very first operation in that handler, does
not make much difference.
And I agree with you, rendering APIs should not change buffer sizes
without notifying the higher levels. My mistake was to assimilate libEGL
with X Core drawing, where buffers do change unpredictably - but that's
probably what we want to address with wayland.
Windowing APIs, on the other hand, are expected to report different
sizes over time, or place arbitrary implementation limits on resizes.
We're all talking about tablets and mobiles these days, and then we let
apps say "I want a 1024x768 window, and I want it now!"? :)

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/20110908/61072f9a/attachment.pgp>