[RFC v2] surface crop & scale protocol extension
spitzak at gmail.com
Tue Nov 12 13:38:46 PST 2013
Pekka Paalanen wrote:
> The surface size has never been limited to multiples of buffer_scale.
> The *buffer* size is.
> Note, that when we talk about surface size, it is always given in the
> surface coordinate units, unless said otherwise.
> You are probably referring to the view size on the output, that is the
> size of the surface drawn on a particular output, measured in output
> pixels. That size will always be a multiple of output_scale, regardless
> of buffer_scale, because the surface size is in integers.
I am assuming the only buffer_scale other than 1 will be to set it equal
to an output_scale. Since the numbers are equal, it is therefore true
that neither the buffer or output surface size can be given in pixels,
only in multiples of the buffer_scale/output_scale.
> We are all just waiting for the use case where this is not sufficient.
Primarily because smooth resizing will require using transparent pixels
to fill in the odd-sized edges, thus losing the ability to use opaque
surfaces, and complicating the api to drawing libraries.
I am also worried that clients will accidentally throw away
higher-precision pointing information by rounding all event coordinates
More information about the wayland-devel