[PATCH 00/15] weston scaling support

[Alexander Larsson]

On tis, 2013-05-28 at 18:33 -0700, Bill Spitzak wrote:
> On 05/28/2013 06:40 AM, Pekka Paalanen wrote:
> 
> > If you really need an output scaling factor like 1.5, then you report it
> > as either 1 or 2, and do a compensating scaling in the compositor to
> > achieve 1.5. That is the best compromize I can imagine, since to be
> > honest, 1.5 does not work for the protocol nor the clients' rendering.
> 
> Then it is impossible for the client to render 1:1 with this output's 
> pixels. All it can do is set the scale to 1 and have it scaled up by 1.5 
> to get the output pixels, or set the scale to 2 and have it scaled down 
> to .75 to get the pixels.
> 
> I don't think you can avoid non-integer scaling. What happens if a 
> client says it's scale is 3 and the output has a scale of 2? This is not 
> just hypothetical, it will certainly happen if there is both a scale 3 
> and scale 2 output on the device.

Yes, the actual scaling that the compositor has to apply from the buffer
to a given output may be fractional. However, the scaling factor between
the buffer and the surface (i.e. in pels or in global compositor
relative sizes) is an integer. This means that any integer position in
surface space corresponds to an integer in buffer space, so for instance
a pixman region (in ints) damage or clip region in surface space
corresponds to an exact pixman region in buffer coordinates. And, this
is the transformation that the compositor really cares about internally
(e.g. for input scaling, clipping, dirty tracking, etc) rather than the
final drawing translation.