On Wed, 13 Nov 2013 12:26:41 -0800 Bill Spitzak <[email protected]> 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 _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
