RFC: surface crop and scale protocol extension

[Pekka Paalanen]

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?

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?

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.

Does anyone disagree?


Thanks,
pq