[PATCH weston 4/8] protocol: crop & scale RFC v3
spitzak at gmail.com
Tue Nov 26 12:47:07 PST 2013
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
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.
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
More information about the wayland-devel