[RFC] wl_surface scale and crop protocol extension

John Kåre Alsaker john.kare.alsaker at gmail.com
Tue Apr 30 16:16:23 PDT 2013


On Tue, Apr 30, 2013 at 10:49 PM, Jason Ekstrand <jason at jlekstrand.net>wrote:

> On Tue, Apr 30, 2013 at 2:29 PM, Bill Spitzak <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.


> 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...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130501/2b7ab322/attachment.html>


More information about the wayland-devel mailing list