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.
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
