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

[Bill Spitzak]

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.

> +      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.

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.

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.

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?