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
to pixels.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
