I feel configure events and requests are messed up

[Giovanni Campagna]

Il giorno mer, 07/09/2011 alle 16.35 -0400, Kristian Høgsberg ha
scritto:
> On Wed, Sep 7, 2011 at 4:27 PM, Giovanni Campagna
> <scampa.giovanni at gmail.com> wrote:
> > Il giorno mer, 07/09/2011 alle 10.33 -0700, Bill Spitzak ha scritto:
> >> In Wayland the client allocates the buffer, not the compositor.
> >>
> >> I think this is what is leading to the confusion here. The compositor
> >> has no say over how big the buffer is. Instead the client controls it
> >> and tells the compositor what the resulting size is.
> >>
> >> To cause futher confusion there is an assumption that the compositor
> >> will then map this entire buffer onto the screen as a window, thus
> >> leading to worry that the client can force the screen to be obscured,
> >> and that it can ignore compositor resizing limits, etc. This is not
> >> true, the compositor can do anything it wants with the buffer, it is in
> >> effect a texture map that it can place part/all of onto the surfaces it
> >> composites onto the screen.
> >
> > As Kristian said earlier, we need coordination between the compositor
> > and the client, which means that when they disagree, we have to decide
> > who is right. I say that the compositor is always right, and the
> > client-side winsys implementation (that is, libwayland-client + libEGL)
> > should enforce this; you say the client is always right and is allowed
> > to create and map whatever buffer.
> > In your model, if the compositor does not map exactly what the client
> > has asked, there is a bug in the compositor; in my model, if the client
> > provides a buffer of the wrong size, there is a bug in the client.
> 
> I don't think that's what Bill is saying.  If there's a disagreement
> between compositor and client, it's typically a broken client. The
> disagreement is what happens in that case.  Just because the client
> can allocate whatever buffer size it wants doesn't mean that the
> compositor has to show all of that.  If the client doesn't behave, you
> can still beat the buffer into shape in the compositor when you
> present it on screen.  There's no reason to force EGL to allocate a
> buffer at the given size.

Well, if we agree that the compositor is in power of mandating sizes,
then I think EGL should collaborate and actively enforce them, at all
places where those sizes are exposed. It doesn't make sense to have
eglQuerySurface saying one thing, gdk_window_get_size saying another,
and then the compositor going its own way and painting half of the
buffer.
Given it's the same people writing the client and the server side of
this, and given it is a protocol (so something that must be agreed
upon), I think it makes sense to have the two sides of communication
collaborating to keep consistency. Application level code, on the other
hand, will always go at length to deviate from protocols, expectations
and conventions, and that's what we should isolate and prevent.

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