[RFC v2] surface crop & scale protocol extension

[Pekka Paalanen]

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

> 
> 
> Pekka Paalanen wrote:
> 
> >> Sounds right. My main concern was that the scale width+height completely 
> >> replaces all uses of the buffer width+height in the visible compositor 
> >> api (the buffer width+height is needed to figure out where the memory 
> >> for the crop region is, but should be ignored otherwise).
> > 
> > This thread is about protocol. It says nothing about Weston's
> > internal implementation details.
> 
> My question *is* about the protocol.
> 
> Let me try again: to a client, after it sends a scale of a 100x100 
> buffer to 200x200, is there any indication of that original 100x100 size 
> in any protocol events or requests afterwards, or does it work precisely 
> the same as though they sent an unscaled 200x200 buffer?

All protocol that deals with surfaces (input, sub-surfaces, shell,
etc...) works in surface coordinates.

Of course both client and compositor will know the true size of the
buffer, but the size of buffer is generally not used in the
protocol beyond determining the surface size or setting the
buffer-to-surface coordinate mapping parameters.


Thanks,
pq