I feel configure events and requests are messed up
spitzak at gmail.com
Thu Sep 8 16:55:08 PDT 2011
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.
More information about the wayland-devel