[RFC] wl_surface scale and crop protocol extension

[Ander Conselvan de Oliveira]

On 05/01/2013 02:16 AM, John Kåre Alsaker wrote:
> On Tue, Apr 30, 2013 at 10:49 PM, Jason Ekstrand <jason at jlekstrand.net
> <mailto:jason at jlekstrand.net>> wrote:
>
>     On Tue, Apr 30, 2013 at 2:29 PM, Bill Spitzak <spitzak at gmail.com
>     <mailto:spitzak at gmail.com>> wrote:
>
>         I'm not clear on why Wayland's design requires adding 2 dummy
>         objects to the api (in this case the "wl_scalar" factory and the
>         per-surface "wl_surface_scalar") rather than just adding new
>         methods to the wl_surface object.
>
>         It seems wasteful for clients and servers to track this whole
>         constellations of id's for the same wl_surface. It also looks
>         too much like X where I had to keep the window, visual, visual
>         id, screen, colormap, gc, and I forget what else, because all
>         the X functions required different arguments types for no
>         discernible reason when they could all be derived from the
>         window id.
>
>         I'm guessing there is a good reason for compatibility but it
>         seems that just adding more message numbers after the
>         already-used ones would work. To avoid collisions between
>         multiple extensions the server could instead send an event
>         saying "the scalar messages to wl_surface start at N" and this
>         single number, rather than an per-surface extra object id, is
>         all the client needs to remember.
>
>
>     I agree that keeping piles of extra objects around may not be the
>     best solution.  However, we cannot simply have "the scaler messages
>     to wl_surface start at N" type message.  This would require
>     substantially altering the wire protocol along with libwayland.
>
> I think adding that would be mostly additions to
> libwayland/wayland-scanner and wouldn't require modifying the wire
> protocol at all.

The protocol allows us to add new requests to a new version of an 
interface. For instance, the set_buffer_transform request was added to 
version 2 of the wl_surface interface.

I believe the scaled video use case is reason enough to add this 
straight to wl_surface.

Cheers,
Ander

>     Even if we did make those changes, I think we would end up right
>     back where we are now having to manage extension proxies so we
>     wouldn't save anything.
>
> We would only have to manage an extension object per connection
> client-side and only one object for all connections server-side, which
> would be a huge improvement over the current state.
>
>     Besides, I'm pretty sure one of Kristian's main ideas in the core
>     wayland protocol is "everything's an extension" so this IS the
>     extension system.
>
> It's more like you can add new object types which may or may not be
> extensions of others, not so much an extension system as a way of doing
> extensions.
>
> We should probably split off any plots for libwayland changes elsewhere...
>
>
>
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>