RFC: surface crop and scale protocol extension

[Tanibata, Nobuhiko (ADITJ/SWG)]

> -----Original Message-----
> From: wayland-devel-bounces at lists.freedesktop.org 
> [mailto:wayland-devel-bounces at lists.freedesktop.org] On 
> Behalf Of Pekka Paalanen
> Sent: Wednesday, December 04, 2013 5:30 PM
> To: Ander Conselvan de Oliveira
> Cc: Jonny Lamb; wayland-devel at lists.freedesktop.org
> Subject: Re: RFC: surface crop and scale protocol extension
> 
> On Wed, 04 Dec 2013 10:06:54 +0200
> Ander Conselvan de Oliveira <conselvan2 at gmail.com> wrote:
> 
> > On 12/04/2013 09:20 AM, Pekka Paalanen wrote:
> > > On Thu, 28 Nov 2013 12:52:15 +0100
> > > Jonny Lamb <jonny.lamb at collabora.co.uk> wrote:
> > >
> > >> Il giorno mar, 26/11/2013 alle 18.19 +0100, Jonny Lamb 
> ha scritto:
> > >>> 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.
> > >>
> > >> Some slightly different protocol designs have been proposed for 
> > >> surface cropping and scaling, so with the idea of making 
> the choice 
> > >> as easy as possible I have prepared branches with the 
> different ideas:
> > >>
> > >> 1. wl_scaler and wl_surface_scaler interfaces:
> > >>
> > >>      This is the patchset I already posted to the list 
> which adds the
> > >>      wl_scaler global object and wl_surface_scaler objects are
> > >>      created per surface:
> > >>
> > >>      http://cgit.freedesktop.org/~jonny/weston/log/?h=scaler
> > >>
> > >>      (The only difference between this branch and the 
> patches sent to
> > >>      the list is the removal of the "open issues" section in the
> > >>      commit message of the commit that adds the protocol XML.)
> > >>
> > >> 2. set_buffer_viewport request on wl_surface:
> > >>
> > >>      No more extra interfaces but a new request on wl_surface:
> > >>
> > >>      http://cgit.freedesktop.org/~jonny/wayland/log/?h=scaler-alt
> > >>      http://cgit.freedesktop.org/~jonny/weston/log/?h=scaler-alt
> > >>
> > >> 3. wl_scaler and wl_viewport interfaces:
> > >>
> > >>      Exactly the same as the first proposal here but
> > >>      wl_surface_scaler renamed to wl_viewport:
> > >>
> > >>      
> > >> http://cgit.freedesktop.org/~jonny/weston/log/?h=scaler-viewport
> > >>
> > >> Choices choices choices!
> > >
> > > I'm a bit surprised no-one has yet given their opinion as 
> a reply to 
> > > this. :-o
> > >
> > > For this one I have even less personal preference than for the 
> > > wl_fixed_t issue, as long as wl_subsurface is not an option.
> > >
> > > If everyone is really indifferent here, then let's go 
> with option 3, 
> > > wl_scaler and wl_viewport, which gives compositor implementations 
> > > the choice to not implement it. Ok?
> > 
> > I'd prefer 2. Is there any good reason a compositor 
> wouldn't implement 
> > this?
> 

I'd perfer 2 as well. The use case "zero-copy video display" of this
feature might be applied to the almost of system. 

> Hmm... sw-based renderer might not want to implement it, if 
> scaling is relatively expensive. Downscaling during 
> composition would be wasteful, but upscaling during 
> composition *might* be a win in total, compared to if the 
> client has to scale to the final size itself first. It's not 
> clear what is better, and it also depends on whether 
> re-compositing is more frequent than committing new scaled buffers.
> 
> Programmable hw based renderers like GL-renderer presumably 
> can always implement crop & scale, no sweat.
> 
> Fixed-function hardware (that is, hw overlays basically) 
> usually support cropping and scaling too. Does anyone know of any
> (relevant) hardware that cannot?

I don't know the all H/Ws but some 2D blit engines e.g. R-CAR and FSL:
imx6 vivante can do it.
But i can not clearly say if there is some limitation to alignment of
memory, it can not support flexible height and width.

> 
> Now I'm leaning towards wl_surface option. So, I can't 
> decide, really. :-D
> 
> Maybe it doesn't make sense to give a choice for compositor 
> implementations here. I can see having crop & scale in 
> wl_surface making clients easier to write, too.
> 

I agree. Compositor can realize a way e.g using H/W 3D, 2D, others, or
combinations of them. 
On clarification of patch for weston, would it be done by pixman api. I
thought it would be done by asking compositor with a matrix to
transform; scale up/down by GL when it is composited.
However, I also think it doesn't make sense to dicuss a specific way
here. 

> Does anyone disagree?
> 
> 
> Thanks,
> pq
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>