[RFC v2] surface crop & scale protocol extension

[Pekka Paalanen]

On Wed, 13 Nov 2013 12:26:41 -0800
Bill Spitzak <spitzak at gmail.com> wrote:

> Pekka Paalanen wrote:
> 
> > Is your whole issue based on the premise, that the output resolution is
> > not a multiple of output_scale?
> 
> I think there is some serious confusion here. Everything here is a 
> multiple of everything else.
> 
> My client is attempting to obey the output_scale on the assumption that 
> this advertised output_scale will produce the best image. It sees an 
> output_scale of 3 and assumes the reason is that the pixels on that 
> output are 3x smaller (1/9 the area) of "standard" pixels.

Ok, let's assume output_scale=3.

> The client says "If I want to produce the best hi-resolution image, I 
> need to use a buffer that is 3x larger in each direction and use a 
> buffer_scale of 1/3".

That is indicated by setting buffer_scale=3 in the protocol.

> Then the client says "I want to use a subsurface and the crop+scale api 
> to blow this 512x512 image up to cover exactly 1024x1024 pixels in my 
> main buffer" (on the assumption that this is also 1024x1024 pixels on 
> the output).
> 
> However instead of sending a 1024x1024 square to the compositor for the 
> dst area, it has to send a 341.3333333 square using fixed-point. This 
> requires everybody to agree on rounding rules, and is misleading because 
> the crop+scale only will work for integer numbers of pixels.

Yes, you cannot use non-integer surface sizes. You cannot express a
surface size, that would result in a 1024x1024 area in output pixels,
because 1024 is not divisible by output_scale=3.

This limitation exists also before crop & scale. Crop & scale cannot
remove this limitation, because the whole Wayland protocol has been
built on surface coordinates and especially surface sizes are integers.


Thanks,
pq