[PATCH 2/2] protocol: Support scaled outputs and surfaces

[Alexander Larsson]

On tor, 2013-05-16 at 10:05 -0500, Jason Ekstrand wrote:

> I still think we can solve this problem better if the clients, instead
> of providing some sort of pre-scaled buffer that matches the output's
> arbitrary scale factor, simply told the compositor which output they
> rendered for. Then everything will be in that outputs coordinates.  If
> the surface ever lands on a different output, the compositor can scale
> everything relative to the selected output.  Surfaces which do not
> specify an output would just get scaled by the factor.  This has three
> advantages.

I don't like this. First of all, there is no way to know the outputs
coordinates other than reading the wl_output transform and scale from
the events. In fact, the output coordinate space is intentinally
"hidden" from the client, as pekka said "The surface
transform, that is private to the compositor, could warp the surface
along a curve for all we care".

Furthermore, claiming that a client renders in output space means that
we lock down the specification of the output transform, as old clients
are claiming to be rendering for a given output. I.e. if we had used
this model before (say we rendered for an output, rather than give a
specific buffer_transform) we wouldn't be able to extend the output
transform by adding a buffer_scale.