RFC: surface crop and scale protocol extension
ppaalanen at gmail.com
Wed Dec 4 00:30:10 PST 2013
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
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,
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?
More information about the wayland-devel