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