[RFC v2] surface crop & scale protocol extension

[Bill Spitzak]

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.