[PATCH weston 7/8] protocol,compositor: split wl_viewport setters

[Pekka Paalanen]

On Fri, 14 Mar 2014 11:54:27 -0700
Bill Spitzak <spitzak at gmail.com> wrote:

> Pekka Paalanen wrote:
> 
> > +    <request name="set_source" since="2">
> > +      <description summary="set the source rectangle for cropping">
> > +	Set the source rectangle of the associated wl_surface. See
> > +	wl_viewport for the description, and relation to the wl_buffer
> > +	size.
> > +
> > +	If width and/or height are negative, the source rectangle is unset
> > +	instead.
> > +
> > +    <request name="set_destination" since="2">
> > +      <description summary="set the surface size for scaling">
> > +	Set the destination size of the associated wl_surface. See
> > +	wl_viewport for the description, and relation to the wl_buffer
> > +	size.
> > +
> > +	If width and/or height are negative or zero, the destination size
> > +	is unset instead.
> 
> I think you may have the <=0 and <0 reversed here. A zero-sized source 
> cannot be used (unless the destination is zero-sized) so that should not 
> be considered valid. But a zero-sized destination does make physical 
> sense (the image is scaled to invisibly tiny).

A zero-sized surface must not exist, hence destination size must be
at least 1x1.

A zero-area source can theoretically exist: you sample the color
exactly at src_x,src_y and use that single color for the whole
surface.

Note, that the size of the wl_buffer is a completely separate thing.

You did point out one corner case, that I should probably
clarify: zero-area source rectangle with unset destination size;
this case I have meant to round up to 1x1 surface size. So, I
should really add a note, that the destination size is always at
least 1x1 in surface coordinates.

I do agree, that excluding 0x0 from legal source rectangle
sizes would be ok, too. Then the minimum would be 1/256 x 1/256,
from the definition of wl_fixed_t. I'll consider that.

> However the result of a zero-sized destination (or a zero-sized source 
> when the destination is unset) can be achieved by the client hiding the 
> surface instead, so I think there is no reason to support it. Therefore 
> I think it would be best if both rectangles used zero to mean unset. 
> This is easier for software to test for with readable code, too.

Right.

> You may also want to reserve negative numbers for future use. They could 
> conceivably do reflections. Not sure if that is useful but it might be 
> best if such negative numbers were errors rather than meaning unset.

We already have a way to do reflections, we do not need yet another
one.

If we make negative numbers an error, I need to add (keep) an error
code for them.


Thanks,
pq