[RFC v2] surface crop & scale protocol extension

[Pekka Paalanen]

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?


Thanks,
pq