[PATCH weston 4/8] protocol: crop & scale RFC v3

[Pekka Paalanen]

On Tue, 26 Nov 2013 12:47:07 -0800
Bill Spitzak <spitzak at gmail.com> wrote:

> Jonny Lamb wrote:
> 
> > Changes in v3:
> > 
> > Disallow zero values for dst_width and dst_height.
> 
> This all looks a lot better.
> 
> > +      The coordinate transformations from buffer pixel coordinates up to
> > +      the surface-local coordinates happen in the following order:
> > +        1. buffer_transform (wl_surface.set_buffer_transform)
> > +        2. buffer_scale (wl_surface.set_buffer_scale)
> > +        3. crop and scale (wl_surface_scaler.set)
> 
> I still feel you *MUST* switch the order of steps 2 and 3 here. The 
> current api restricts what clients can do to a subset of what the 
> hardware is capable of (the dst_rectangle cannot land on any pixels, but 
> only on multiples of buffer_scale). Also this adds some extra pain to 
> specifying the source rectangle because the buffer_scale must be taken 
> into account.
> 
> I am unclear why this is not obvious to everybody here. If in fact I 
> have made a fundamental mistake in understanding this it would be nice 
> if somebody pointed it out.

I have explained all this before. Nothing here has changed.

> > +      If the source rectangle is partially or completely outside of the
> > +      wl_buffer, then the surface contents are undefined (not void), and
> > +      the surface size is still dst_width, dst_height.
> 
> I would still like this to be defined as clamped to edge, but I admit 
> there may be other workarounds.

"Undefined" is mostly likely implemented like that: clamped to
edge, however the surface size is still what the client explicitly
expects. That means the part outside of the buffer will be
transparent, black, garbage, or whatever. We leave it up to the
implementation to choose what is the best option. I doubt anyone would
make the whole surface garbage if just a part is outside the buffer.

> The example is a client wants to uniformly scale a 500x1004 image and 
> fit it in an area that is 100 high and much wider than necessary. The 
> correct scaled image size is 100x200.8. The client would prefer to use a 
> destination rectangle of 100x201 and set the source slightly outside the 
> image with the left edge at -.5 and the right edge at 1004.5.
> 
> If however this will produce random-colored pixels at the left+right 
> edges, the client is forced to use a destination rectangle of 100x200 
> and set the source rectangle left edge to 2 and right edge to 1002. The 
> result is that 2 pixels of data are lost on each edge, rather than the 
> less-objectionable adding of .5 a pixel of smear on each edge.

The "smear" is exactly the same as "random-colored" from the protocol
point of view. What you get depends on the compositor implementation,
just like the method used for scaling (only ever using NEAREST is not
illegal!). If you care about how exactly these things are done, you need
to scale it yourself in the client first.

> Distorting the picture is not an acceptable solution, as the software I 
> am working on requires the user to A/B pictures that are at different 
> resolutions. If different resolutions are distorted differently this 
> does not work.

You mean you do not want the compositor to stretch the image slightly
differently than what the client explicitly requested? I agree, but
there may be cases where that would mean losing a hw overlay and
causing a big performance loss.

> Counter-arguments:
> 
> 1. Our client is already doing this using OpenGL and it is unlikely it 
> will be rewritten to use Wayland's scale anyway.
> 
> 2. The client could make the source buffer 1006 pixels wide. This would 
> also allow the client to choose whether the extra pixels replicate the 
> edge or are a solid color. My main worry is that the buffer may be 
> produced by a library that refuses to do this.
> 
> 3. It may be acceptable to just limit the "undefined" results to not 
> producing unexpected color dots from reading random data (ie it could be 
> clamp-to-edge or black or transparent or many other things, and even 
> vary depending on whether the filter intersects the buffer).
> 
> > +      <arg name="src_x" type="fixed" summary="source rectangle x"/>
> > +      <arg name="src_y" type="fixed" summary="source rectangle y"/>
> > +      <arg name="src_width" type="fixed" summary="source rectangle width"/>
> > +      <arg name="src_height" type="fixed" summary="source rectangle height"/>
> 
> Are these allowed to be arbitrary fractions, or is this rectangle in 
> fixed units only to work around the fact that it is in multples of 
> buffer_scale?

The values are allowed to be arbitrary, so that you can zoom in to
partial buffer pixels if you want to. They are not meant to counter
buffer_scale, which you will likely choose to set to 1 anyway when
using crop & scale and regardless of output scale.


Thanks,
pq