RFC: surface crop and scale protocol extension

[Pekka Paalanen]

On Tue, 26 Nov 2013 18:19:40 +0100
Jonny Lamb <jonny.lamb at collabora.co.uk> wrote:

> Hello.
> 
> This is the initial version of the weston implementation of the
> wl_scaler protocol extension for surface cropping and scaling. It is
> based on the extension RFC version 3, written by Pekka Paalanen.
> Earlier versions are:
> 
> http://lists.freedesktop.org/archives/wayland-devel/2013-April/008927.html
> http://lists.freedesktop.org/archives/wayland-devel/2013-November/011869.html
> 
> RFC version 3 has one change: disallow zero values for dst_width and
> dst_height, which is similar to a change I proposed for surface
> scaling and transformations to wayland-devel a few days ago.
> 
> This initial patch set is in two parts:
> 
>  1. add new weston_buffer_viewport struct for buffer transformation
>     and scaling, then related cleanups in working out surface size,
> 
>  2. implement cropping and scaling support in GL and pixman renderers,
>     then add a demo client to test out these features.
> 
> The first part (by Pekka) can be pushed as is as it has nothing to do
> with wl_scaler, but just cleans up related code in preparation for
> wl_scaler code.
> 
> Cropping and scaling has not yet been implemented in the Raspberry Pi
> renderer; this will happen at some point in the future.
> 
> Comments appreciated.
> 

Hi,

I might add some notes: I have looked at the implementation, and it
seems good. The pixman renderer has an issue, but gl-renderer
works fine.

If you take weston-scaler app and rotate its window
(Mod+RightMouseButton-drag), you see that the cropping does not work
properly while rotated in non-90-degrees-steps. Pixman renderer paints
the whole bounding box regardless of the crop, which reveals red - the
parts of the wl_buffer that are supposed to be cropped away. I
attempted to set a clip for the pixman source image, but it seems to
get ignored. Rotation on pixman renderer relies on sampling outside of
the surface to produce transparent rather than hit valid buffer area.

We have not even tried to hook up the drm-backend planes for crop &
scaled surfaces, since they are disabled anyway.

If the protocol interface is ok, then this is the code we would like to
see merged. Some commits can be squashed if wanted, and the open issues
comments can be removed from the protocol commit, but otherwise I think
this is ready for merging. The loose ends in the renderers and backends
can be fixed later.

So, it's all up to which protocol interface style we want: the proposed
one, or only a new request in wl_surface.


Thanks,
pq