[RFC v2] surface crop & scale protocol extension

[Pekka Paalanen]

On Fri, 8 Nov 2013 13:33:22 +0200
Pekka Paalanen <ppaalanen at gmail.com> wrote:

>   <interface name="wl_surface_scaler" version="1">
>     <description summary="crop and scale interface to a wl_surface">
>       An additional interface to a wl_surface object, which allows the
>       client to specify the cropping and scaling of the surface
>       contents.
> 
>       This interface allows to define the source rectangle (src_x,
>       src_y, src_width, src_height) from where to take the wl_buffer
>       contents, and scale that to destination size (dst_width,
>       dst_height). This state is double-buffered, and is applied on the
>       next wl_surface.commit.
> 
>       Before the first set request, the wl_surface still behaves as if
>       there was no crop and scale state. That is, no scaling is applied,
>       and the surface size is as defined in wl_surface.attach.
> 
>       The crop and scale state causes the surface size to become
>       dst_width, dst_height. This overrides whatever the attached
>       wl_buffer size is, unless the wl_buffer is NULL. If the wl_buffer is
>       NULL, the surface has no content and therefore no size.
> 
>       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)
>       This means, that the source rectangle coordinates of crop and scale
>       are given in the coordinates after the buffer transform and scale,
>       i.e. in the coordinates that would be the surface-local coordinates
>       if the crop and scale was not applied.

Is the above the preferred order of coordinate transformations for the
clients?

Or would you rather have src_x, src_y, src_width, src_height always
defined in buffer coordinates, and then buffer_transform and
buffer_scale (with their requirement of size being a
multiple of buffer_scale) applied to dst_width and dst_height instead?

In the latter case, the surface size would be affected by all of
buffer_transform, buffer_scale, dst_width and dst_height.

Depending on what coordinate space you process your input in, you might
have more, less, or no difference in the amount of needed calculations.
And the same for how your video components define their parameters.

Therefore this is really a question for people familiar with the
various video libraries like gstreamer.

In the end, I see no other difference between the transformation orders
than convenience: calculations you might be able to avoid, some lines
of code you can skip writing. The same piece of code has to control both
the wl_surface interface and the wl_surface_scaler interface anyway.


Thanks,
pq

> 
>       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.
> 
>       The x, y arguments of wl_surface.attach are applied as normal to
>       the surface. They indicate how many pixels to remove from the
>       surface size from the left and the top. In other words, they are
>       still in the surface-local coordinate system, just like dst_width
>       and dst_height are.
> 
>       If the wl_surface associated with the wl_surface_scaler is
>       destroyed, the wl_surface_scaler object becomes inert.
> 
>       If the wl_surface_scaler object is destroyed, the crop and scale
>       state is removed from the wl_surface. The change will be applied
>       on the next wl_surface.commit.
>     </description>
> 
>     <request name="destroy" type="destructor">
>       <description summary="remove scaling and cropping from the surface">
> 	The associated wl_surface's crop and scale state is removed.
> 	The change is applied on the next wl_surface.commit.
>       </description>
>     </request>
> 
>     <enum name="error">
>       <entry name="bad_value" value="0"
>              summary="negative values in width or height"/>
>     </enum>
> 
>     <request name="set">
>       <description summary="set the crop and scale state">
> 	Set the crop and scale state of the associated wl_surface. See
> 	wl_surface_scaler for the description, and relation to the
> 	wl_buffer size.
> 
> 	If any of src_width, src_height, dst_width, and dst_height is
> 	negative, the bad_value protocol error is raised.
> 
> 	The crop and scale state is double-buffered state, and will be
> 	applied on the next wl_surface.commit.
> 
> 	Arguments dst_x and dst_y do not exist here, use the x and y
> 	arguments to wl_surface.attach. The x, y, dst_width, and dst_height
> 	define the surface-local coordinate system irrespective of the
> 	attached wl_buffer size.
>       </description>
> 
>       <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"/>
>       <arg name="dst_width" type="int" summary="surface width"/>
>       <arg name="dst_height" type="int" summary="surface height"/>
>     </request>
> 
>   </interface>
> </protocol>
> 
> 
> Thanks,
> pq