[PATCH 00/15] weston scaling support

[Bill Spitzak]

On 05/29/2013 12:31 AM, Alexander Larsson wrote:

>> 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.

The compositor will produce regions that are not integers in surface 
space. For instance the damage from an overlapping window atop a surface 
who's scale is not an integer will produce a region that is fractional 
in that lower surface's space.

I agree that the compositor will then immediately expand these to 
integer buffer coordinates, but I don't think limiting the scales to 
integers is buying you anything.

The client should send regions to the compositor in buffer pixels. It 
has to use these coordinates to draw and things like "opaque region" are 
much more related to drawing than anything else.