[RFC] wl_surface scale and crop protocol extension

[Jason Ekstrand]

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.

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.


> I'm guessing this is not going to be changed, so perhaps this mechanism
> can at least be formalized so the documentation can be fixed to list "set
> scaling" under wl_surface where you expect to find it, and then briefly
> describes the factory name, and fixed rules determine the rest of the api.
> I would define the following:
>
>  1. A "factory" (wl_scalar in this case) can only be used to create one
> class of sub-object (the wl_surface_scalar in this case) per parent class.
> It provides one method to create this object that takes one argument, the
> id of the "parent" object (a wl_surface in this case).
>
>  2. The name of the subobject class is well-defined by the factory and
> parent class names. The proposed "wl_surface_scalar" disagrees with
> "wl_shell_surface" here.
>
>  3. The name of the method to get the sub-object from the factory is
> well-defined. It looks like the standard is "get_<subobjectclass>", though
> "get" would be nice in any language with overloading.
>
>  4. All factories act the same if an attempt to create more than one
> subobject per parent is done. It looks like some throw errors and others
> create multiple objects. If they throw errors the error enum should be
> shared by all factories.
>
> As I certainly see some similarity in the existing Wayland api's, it seems
> there is at least informal standardization. Making it part of the design
> spec and deprecating any irregular api would help.


I think there needs to be a distinction made here between an extension to
wl_surface and a surface role.  The idea of a surface role is that a
surface can be a subsurface, a shell surface, a cursor surface etc, but
only one at any given time.  This was (as far as I can tell) somewhat
formalized during some of the discussion around subsurfaces.

This is very different from adding scaling to a surface.  For scaling, we
are effectively just adding additional requests to the wl_surface object.
In this case, I would tend to agree that an entire extra object may be
overkill.

--Jason Ekstrand
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130430/9c5659e0/attachment.html>