surface buffer cardinality and outputs

[Bill Spitzak]

I think the compositor has to be able to tell the client what transform 
it plans to apply to the surface, and the client when setting the buffer 
is able to say what transform it used to draw it.

This would also replace the current indications of 90 degree rotations.

The original email does point out another problem where a surface is on 
multiple outputs and thus subject to multiple transforms. Perhaps the 
client can attach multiple buffers for a surface, with an indication as 
to which output the buffer is for. This probably also the ability for 
the client to say that the buffer only represents a clipped area of the 
surface, which I have suggested before but people here don't seem to 
like that idea.

Pekka Paalanen wrote:
> On Wed, 13 Mar 2013 19:52:55 +0100
> Sylvain BERTRAND <sylware at legeek.net> wrote:
> 
>> The other option would be to ignore those output properties, and
>> the compositor would manage something with an output agnostic
>> buffer.  In that case, we would remove the subpixel property from
>> the output to stay consistent (mode is used for shell surface
>> fullscreen).
> 
> Btw. the sub-pixel property has also other issues: if the compositor
> does any surface transformations instead of pure translation, any
> sub-pixel rendering will become incorrect. That's a gap we haven't
> really tried to solve yet, either.
> 
> 
> Thanks,
> pq
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel