[PATCH] compositor: implement a stack of surface transformations

[Bill Spitzak]

This is why I would prefer that the clients do full screen by finding 
out the size of the monitor and directly setting the transform to how 
they fill the screen. Then the client knows exactly what transform is 
happening, and can concatenate any other transforms in it's own code.

Clients are going to need to know the actual transform anyway. They may 
very well be controlling hardware that is outside the compositor's 
control, such as other specialized pointing devices or projectors.

The compositor must limited the "fixing" of misbehaving windows to 
clipping and/or padding with solid rectangles, rather than altering the 
client's requested transform.

As always, I very strongly believe the client *must* have final say over 
the position and contents of the windows, including the borders. This is 
the only way to avoid the latency problems that make X work so badly.

Pekka Paalanen wrote:
> Having at most one transformation object attached to a surface is not
> enough anymore. If we have a surface that needs to be scaled to
> fullscreen, and then we have the zoom animation, we already need two
> transformations combined.

> Note: surface drawing should honour all kinds of transformations, but
> not damage region code nor input event translating code take
> transformations into account, AFAICT. Therefore anything but translation
> will probably behave badly until they are fixed.

The dirty bit is probably useful for deferring the inverted matrix 
calculation that is necessary for these.

You will need to find the determinant even without any input/damage 
events, because non-invertible matrices should cause the surface to be 
unmapped (since at least one axis is scaled by zero).

I was under the impression that Wayland had no such thing as "damage 
regions". The surface belongs to the client, so it does not seem like 
there is any way for it to be "damaged" unless the client does it itself?