client side decorations

[Bill Spitzak]

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.