[RFC v2] surface crop & scale protocol extension
ppaalanen at gmail.com
Wed Nov 13 01:54:38 PST 2013
On Tue, 12 Nov 2013 16:14:36 -0800
Bill Spitzak <spitzak at gmail.com> wrote:
> Pekka Paalanen wrote:
> >> The source rectangle *must* be in buffer pixels. Putting it in
> >> buffer_scale units makes absolutely no sense, as the buffer_scale is in
> >> effect ignored for this surface, overridden entirely by the scaling.
> > That means that dst_width and dst_height will be required to be in
> > multiples of buffer_scale.
> I am rather confused about this and possibly misunderstanding what
> Wayland is doing. Here is an example of what I think the current design is:
> Imagine there is an output_scale of 3 (chosen to not be a power of 2). A
> client is aware of this and wishes to draw a full-resolution display
> that is 2000x2000 pixels and make a subwindow that scales a 512x512
> picture to fill a 1000x1000 pixel square.
Is your whole issue based on the premise, that the output resolution is
not a multiple of output_scale?
Just like you deduced, it won't work. It not working has nothing to do
with crop & scale state.
Alexander, did you have any ideas for the case when someone sets
output_scale so that output resolution is not divisible by it?
More information about the wayland-devel