client side decorations
spitzak at gmail.com
Wed May 11 11:40:51 PDT 2011
Michal Suchanek wrote:
> I guess there is one thing that can be done. The compositor could
> publish a hint to the application that it takes care of decorating the
> windows (even if it is a tiling WM and in fact does not but the user
> does not want any decorations in the first place)
Indeed this looks like a good idea. In fact doing some sketches it
appears to be necessary for the compositor to tell the client to delete
the decorations on each edge independently.
> and the client could
> publish a hint that it does draw decorations and its windows should
> not be decorated by the compositor (or it does not want decorations
> because it is a clock window and decorating it makes no sense).
I don't think the compositor should ever decorate the windows so I very
much disagree with any idea like this.
It cannot draw into the texture for the window, as that memory belongs
to the client. If the client is doing internal double-buffering, the
compositor does not even have a pointer to the texture!
Therefore the compositor would have to add extra surfaces that are the
decorations. This could either be a larger underlay window, an overlay
with a big transparent hole, or thin windows placed around the edges.
The problem here is that resizing the window needs to be an atomic
operation so the user never sees a partial update. This means that both
windows must resize and have their image replaced in the same operation,
while the images are produced by two different processes! This sounds
very complex and difficult.
When you add to this the insane amount of little details that clients
need to send to control the decorations (such as whether there should be
a resize box, etc) I think it is nonsense to ever consider such things.
More information about the wayland-devel