I feel configure events and requests are messed up

[Bill Spitzak]

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.

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.

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.