I feel configure events and requests are messed up

Wed Sep 7 05:35:36 PDT 2011

Il giorno mar, 06/09/2011 alle 22.54 -0400, Kristian Høgsberg ha
scritto:
> 2011/9/6 Giovanni Campagna <scampa.giovanni at gmail.com>:
> > Il giorno mar, 06/09/2011 alle 17.31 -0400, Kristian Høgsberg ha
> > scritto:
> ...
> >> Maybe you should introduce yourself and what you're working on before
> >> threatening to break protocol?  I don't know what you're trying to do.
> >
> > Right, sorry, I should have done it before. Sorry also if my wording has
> > been strong so far, but my reading of the first reply was "it is better
> > like this, and we will never ever change it", even if X11 has done to
> > opposite for more than 20 years, with fairly good results (at least on
> > the management side).
> 
> X has certainly been around for a long time, but that doesn't mean
> that the way it does it is the only way it can be done.  But more
> importantly, Wayland is fundamentally different in a few key areas
> that affect window management: the window manager is built into the
> display server, we're always compositing and rendering happens client
> side.  So for a start, there are only two processes involved in window
> management (the compositor and the client) vs X server, WM and client.

Well, when it comes to window sizing, not just X but also Win32 and
Quartz have explicit request on the window object for changing the size,
and they acknowledge that when you receive a resize event, all buffers
have already changed size. There is no way for application code to
ignore a resize event (except that queuing another resize request) and
in fact most applications ignore resize events altogether, focusing only
the resulting paint/expose events.

> > Anyway, I'm working on porting Mutter to Wayland,
> 
> Awesome, happy to hear that.
> 
> > and in various parts
> > the current X11 code base assumes that it can resize to whatever size it
> > likes, and that ConfigureRequests from other clients are just that,
> > requests, not orders.
> > There is a fair amount of code (dating back to previous century for a
> > big part) dealing with correctly sizing windows, in presence of
> > constraints, struts, particular user operations, etc. and the window
> > manager simply expects that windows won't get in the way (or if they do,
> > they do very clearly with WM_NORMAL_STATE, so the WM knows it).
> > For example, if the window won't maximize, Mutter will desensitize the
> > maximize item in the window menu and the maximize button in the title
> > bar, as well as not showing the light blue overlay when dragging to the
> > top, and same for edge tiling. All this is not possible if the final
> > decision is in the hands of clients, rather than the compositor.
> 
> Again, I don't see specifically what it is here that you can't do with
> the current protocol.  The compositor can resize a surface to whatever
> size it wants, independent of the client.  This is something that
> under X would happen between WM and X which is why X has those
> requests, but in Wayland, it all happens internally in the compositor.
>  And I think you're overlooking that even on X, resizing a window is
> always a cooperative affair between the WM and client.  The client
> always make the final decision on what it renders into the window, no
> matter what size you insist the window is.  If you try to force a
> window to be a different size than what the client thinks it should
> be, on Wayland as well as X, you will have to "make up pixels", ie pad
> with a background color or similar hacks.  Under X, the X server will
> do that for you with the automatic rendering, under Wayland you have
> to hack it in the compositor.  But the point is, you should never have
> to do that, the client should always provide you with a buffer at the
> size you ask for instead.

Yes, but one thing is the toolkit always providing a buffer
appropriately sized, because the protocol mandates so (and therefore the
compositor woulp clip only if the protocol is violate), another is the
client notifying application level code, that independently decides if
he likes the new size.
Currently, in X, Win32, Quartz (possibly other), drawing surfaces are
always setup to clip client-side to the actual window size and there is
no way to remove the clip, because the underlying buffer is already
resized when the application is notified. In wayland, on the other hand,
the buffer is not there until you call wl_egl_window_resize (see the
other email about my position on wl_egl_window) and then make some GL
call to allocate it.
It should be explicitly forbidden to attach a new buffer of the wrong
size. Synchronization on the user resize path should happen by delaying
the attachment of the new buffer until it has been redrawn completely by
app code.

> 
> As for all the struts and snapping logic during resizing you mention,
> what problem do you see there?  It should all work with Wayland as
> well; the compositor grabs the pointer when resizing, looks through
> all its constraints and then figure what size it thinks the window
> should be, then sends the configure event to the client to ask for a
> buffer at that size.  The client will typically provide that, but the
> client has the option to provide a smaller buffer, in case it wants to
> enforce resizing constraints such as character cell resizing or aspect
> ration or even custom constraints.

Without the equivalent of WM_SIZE_HINTS, the compositor does not know
what constraints a window may place on resizing, and therefore does not
know what actions are allowed (for example, maximizing is not just a
matter of a single flag: it may be allowed in certain work area
configurations and not in other)
When it comes to character cell resizing, mutter also draws a small
window at the center of the resized one, showing "N x M". I'm not sure
this should be moved to the client-side, but if we keep it in the
compositor, we need the communicate character cells.

> Finally, wl_shell is far from complete.  It's intended to encapsulate
> the interactions desktop clients have with a desktop shell (ie,
> traditional linux desktop scenario) and play the same role for Wayland
> as EWMH does for X.  For example, the maximize capability you mention
> needs to be communicated so that when moving the window, mutter will
> know whether or not to show the blue overlay.  And many other things
> such as window title and window icon.  I've just not tried to tackle
> that, since I don't want to specify that protocol, unless I'm also
> implementing it.

Well, I've prepared a branch locally, that includes everything I think
is needed for window management (including some niceties in the client
side API, like automatic caching of properties). I can send out patches,
but I think a public branch would be easier to review and discuss.

> >> >> 2. There is a compostitor->client call that says "the user is trying to
> >> >> resize the window to be like this". The compositor assumes the client
> >> >> will respond with the above resize call, or something similar (ie the
> >> >> client can fix the call to round the call the increments and aspect
> >> >> ratios and any other rules it wants).
> >> >
> >> > And this call is wrong. The compositor shouldn't ask, it should notify
> >> > that something is changed. Window sizes are server state, and should be
> >> > treated like that (including the possibility to change at any time).
> >>
> >> I think this is where some of the confusion comes from.  In Wayland,
> >> windows don't change size without the client being involved.  You
> >> can't meaningfully resize a window without the client rendering new
> >> content.  The compositor can draw an outline as it resizes the window
> >> and only send the configure event to the client once the resizing is
> >> done, but you can't render the window at a different size without the
> >> client providing the content.
> >
> > Again, I think rendering a window has nothing to do with configuring a
> > window. You can stop updating the window in the compositor, but you need
> > some why to tell client and server state that the window size is
> > changed, even if the buffer is stale. Otherwise you're stuck with this
> > mess in which the real window size is taken from the size of the last
> > attached buffer...
> 
> Resizing a window requires repainting the window at the new size.
> From the client point of view, there is no other meaningful size than
> the size of the last attached buffer.  We may need to send an event
> back to a client if the compositor rejects the proposed buffer attach
> so the client can deal with that gracefully.  However, the client
> knows the size the server wants it to be, and if it's not complying
> with that, the server may have to "make up pixels" or deal with it
> some other way, but there's nothing more we can tell the client.

Resizing a window involves repainting it, but it's not just that. You
need to repaint the decorations, recalculate constraints, update input
areas...
If we split programmatic resizes (advisory) from user/compositor
initiated ones (mandatory), then we're done, and we don't need to make
up for pixels, unless the application is buggy and ignores what the
toolkit says.

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