RFC: surface crop and scale protocol extension

[Ander Conselvan de Oliveira]

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?

Cheers,
Ander