I feel configure events and requests are messed up
scampa.giovanni at gmail.com
Fri Sep 9 02:59:19 PDT 2011
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).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 316 bytes
Desc: This is a digitally signed message part
More information about the wayland-devel