[PATCH 00/15] weston scaling support

[Alexander Larsson]

On ons, 2013-05-29 at 07:55 -0700, Bill Spitzak wrote:
> 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.

Damage from clients is in surface space, which will be in integer
fraction of the output space. Its true that it may be a fractional
coordinate of the buffer space of a window below it, but it will be an
integer coordinate in both windows *surface* space and the output space.
So, you can clip the output drawing to integer coordinates (well, you
have to, can't draw half an output pixel) and let the actual scaling to
fractional coordinates happen purely in the implementation of the
drawing operation.