surface buffer cardinality and outputs

[Bill Spitzak]

Jason Ekstrand wrote:

>> For sub-pixel rendering the solution i have been thinking for a while
>> but still haven't had time to prototype on weston, is to have weston
>> send the transformation matrix to the client have the client render in
>> screen coordinate space and when commiting its surface the client
>> would also tell which transformation matrix it did use.

> Yes, adding some support for that might be a good idea.  However, this
> becomes a bit of an issue because the surface might not be rectangular
> anymore or it might be rotated.  How do you recommend getting around
> this?

If the client ignores the transform sent from the compositor, then it 
will draw a rectangular image that fills the buffer it allocated.

If the client uses the transform sent from the compositor then it will 
realize that it's rectangular image when transformed has a larger 
bounding box and will allocate a buffer of that size, clear the unused 
area, and draw the rotated rectangle.

The client is going to have to be able to tell the compositor that the 
buffer image represents a surface of a given rectangular size with a 
given transform (the compositor cannot get the rectangle back from the 
buffer size and transform as there are many possible rectangles at the 
given angle that fill a given bounding box). This means this information 
must be separated from the buffer size.

This will also allow a client to specify a subrectangle of the buffer as 
a surface, and (more importantly imho) specify that the buffer does not 
fill the surface, for instances where it knows the decorations are 
clipped off.