[RFC] wl_surface scale and crop protocol extension

[Pekka Paalanen]

On Tue, 30 Apr 2013 15:49:16 -0500
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.  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.
> 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.
> 
> In the case of the scaling extension, it might be possible to simply
> have the wl_surface_scaler interface have a single request that
> takes, as its first argument, a new_id containing the surface to
> scale.  This way it can be called "on the surface" without the extra
> object.

Well, it would still have the factory object as its first C function
call argument, and the wl_surface the second.

But if someone wrapped that into, say, a C++ class API anyway, it would
all be just WlSurface methods.

We just cannot design a protocol like a C API, because "oops, it
returned an error" is equivalent to a segfault, pretty much. If we
start returning non-fatal errors, we drown in a swamp of roundtrips.
Like you-know-what-11.

Really, the protocol bindings are not meant as a nice library API,
they are just protocol bindings. Protocol objects are cheap.

> I think the reason to make it separate is so that it's an optional
> extension.  If we put clipping/scaling in wl_surface, then EVERY
> compositor will have to support it in order to be a compliant
> compositor.

Indeed. The other alternative, if we added methods directly into
wl_surface, would be to add also an extension bitmask event, that would
tell which methods are actually implemented. And then extend the
bitmask, when the first 32 bits are used...


Thanks,
pq