I feel configure events and requests are messed up

[Mike Paquette]

I just thought I'd chime in with a little background information on Quartz.  This is purely informational, to give everyone an idea of how these issues were handled elsewhere.  There are lots of possible solutions and tradeoffs.

I'm just kibitzing.  Kristian is driving.  :-)

On Sep 7, 2011, at 5:35 AM, Giovanni Campagna wrote:
> 
> 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.

The Quartz model permits two forms of window resize. 

In the first, applications simply request a new window size, through the appropriate client side library (e.g., Carbon or Cocoa).  The window server performs the resize synchronously, while flagging the window content invalid so it doesn't accidentally get flushed to the display as a side effect of another app's activity.  Once the content is redrawn as appropriate for the size, the client side library informs the server the content is ready to be flushed to the display.   This mechanism is used when the app explicitly places windows, and when a client size modal loop is handling window resize (as in some Carbon apps) in response to user gestures.

In the second form, the client application or framework (library) has delegated user gesture resizing responsibility to the Quartz window server.  A 'shape', or arbitrary region or set of regions of the window is designated for use as a resize area, bound to a gesture such as a left mouse button drag event sequence.   When a resize gesture is started, the server posts a synchronous notification to the client (synchronous in that the server promises not to mess with the buffer until it knows the client has seen the notification or determines the client is unresponsive).  The client application maps this notification into something appropriate, such as the NSWindow delegate "windowWillResize" message.   As the server resizes the window as part of the continuing drag operation, periodically it posts notifications to the app that the window has resized, which are mapped to NSWindow delegate "windowDidResize" messages.   This drives the live updating of window content as part of window resizing.

The "windowDidResize" messages are also used by the client app or framework to implement any custom snapping logic.  While better handled (IMHO) by doing a client side modal loop to implement the resize or movement operation, the client may also 'snap' a window to a new size and origin when handling this message.

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

Quartz handles this by always having the server vend the buffer.  This lets it do things like swap the buffer type (dumb memory vs accelerated GL surface, for example) or buffer accelerator binding when moving across display devices, as well as honoring device-specific oddities (supported pixel formats, interesting backing size constraints, etc.)  Apps that are not prepared to handle this sort of buffer behavior (primarily ones using client frameworks that let them poke at pixels directly) opt out, either explicitly, or as an implicit property set up by a client framework.

A client may construct an OpenGL buffer to it's own specifications and bind it to a window. The surface may be bound above a window, in which case it appears as a rectangular region that obscures the content of the window buffer proper, while still being clipped and shadowed by other windows.  The surface may also be bound BELOW a window, such that it only shows through parts of a window that are drawn with a transparent color, or that are clipped out of the window shape.  (This is commonly used for video players, so that UI elements such as the Play button and position slider can optionally apear over the live video.)   Think of it as a sort of special case child window.