[RFC v2] surface crop & scale protocol extension

[Pekka Paalanen]

On Mon, 11 Nov 2013 10:24:33 -0800
Bill Spitzak <spitzak at gmail.com> wrote:

> Pekka Paalanen wrote:
> 
> > Clients will always specify surface content in blocks of
> > buffer_scale x buffer_scale pixels. That is how it was before, and
> > that is how the crop & scale extension uses it.
> > 
> > In other words, everything is still in surface coordinate units,
> > just like before.
> 
> Yes I understand this.
> 
> IMHO this design is incorrect however. A client cannot take full 
> advantage of all possible surface sizes because they must be multiples 
> of the buffer scale.
> 
> In any case this really is a problem with the buffer_scale api. I think 
> it will be fixed once somebody tries to write a serious application that 
> takes advantage of a hi-res screen.

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.

We are all just waiting for the use case where this is not sufficient.
- pq