[RFC v2] surface crop & scale protocol extension
ppaalanen at gmail.com
Thu Nov 14 01:28:55 PST 2013
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.
More information about the wayland-devel