I feel configure events and requests are messed up

[Giovanni Campagna]

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

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

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