I feel configure events and requests are messed up

[Giovanni Campagna]

Il giorno gio, 08/09/2011 alle 16.55 -0700, Bill Spitzak ha scritto:
> Giovanni Campagna wrote:
> 
> > Yes, but in the middle of this is policy. If the originator of a resize
> > is not the user, how the application can know that the new size is good?
> > We need some way for central policy to kick in, and that's what I'm
> > asking for with the explicit "configure" request. All the rest,
> > including buffer sizes, is tangential and a big misunderstanding caused
> > by my original email.
> 
> There does seem to be a lot of misunderstanding, I'm thinking. This is 
> my understanding of things where I believe there is confusion (please 
> correct me if I am wrong!):
> 
> 1. "client" means the process that is not the compositor process. The 
> "client" includes the toolkit library and all code that is calculating 
> drawn pixels and putting them into the image, such as cairo. Even OpenGL 
> hardware acceleration is part of the client, provided the hardware is 
> writing to the image the client owns.
> 
> 2. The "image" is allocated by the "client". As believe this can be done 
> with malloc, although wayland provides some calls so that the allocated 
> memory is more likely to be used directly by the wayland compositor, 
> rather than having to be copied. I think it should be obvious that only 
> the client can free or realloc memory it allocated with malloc.
> 
> 3. Wayland uses this "image" as a source, the same way a 3D renderer 
> uses a texture map. The 3D renderer is certainly able to resize, clip, 
> and pad texture maps to any shape it requires to put on the object, and 
> is free to add other graphics besides what is in that texture map. In a 
> 3D renderer, making the texture map larger does not make the object 
> enlarge to fill the scene.

All of this is correct, but see below.

> For resizing there needs to be EXACTLY these three calls. I am not sure 
> what they are called and the lack of terms is causing confusion as well:
> 
> 1. A client->compositor call that says "here is the new buffer 
> containing the image I want displayed, and here is how big it is, and 
> here is other information about the stride and pixel format and how the 
> memory is allocated, etc". Think about pixel format and you should see 
> how pointless any idea that the compositor can ignore or disobey this 
> call. This call may also contain not-strictly necessary stuff, such as 
> the position and stacking order of the window, and whether the window 
> should be mapped.
> 
> 2. A compositor->client call that says "the compositor thinks the window 
> should be this big". The client is expected to obey this as closely as 
> it can and then allocate and draw the new image, then make the above 
> call to indicate the result. The compositor must be written so that a 
> client that ignores this or makes a totally different size will not 
> cause a crash or unusable display.
> 
> 3. A client->compositor call that says "the client thinks the window 
> should be this big and at this location". The compositor is expected to 
> respond by sending the above call back with the size changed to whatever 
> limits it imposes, and may also send similar messages to other windows 
> (for instance to resize them in a tiled layout). The compositor can also 
> ignore this call. I believe this is the "configure" you asked for above.

That's exactly what I meant. There is no such request in current
wayland, and I'm glad you acknowledge it's needed.

> In addition Wayland could probably use the following call, which would 
> (IMHO) give 100% of the advantages of the X11 window manager without any 
> of the problems:
> 
> 1. A client->compositor call that says "the user is dragging the mouse 
> and I have decided it is a window resize/raise/move of this type, please 
> handle it". The compositor is expected to track the resizes and send the 
>    resize requests back, as well as applying any of it's rules, such as 
> snapping to edges or tiled windows.

Yes, wayland has this (wl_shell.move + wl_shell.resize), as X11 has it
(_NET_WM_MOVERESIZE). No need for changes here (except maybe
consolidating move and resize).

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