<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 30, 2013 at 2:29 PM, Bill Spitzak <span dir="ltr"><<a href="mailto:spitzak@gmail.com" target="_blank">spitzak@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>

<br>
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.<br>

<br>
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.<br>
</blockquote><div><br></div><div>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.<br>
<br>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.<br>
<br></div><div>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.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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:<br>

<br>
 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).<br>

<br>
 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.<br>
<br>
 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.<br>

<br>
 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.<br>

<br>
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.</blockquote></div>
<br></div><div class="gmail_extra">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.<br>
<br>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.<br>
<br></div><div class="gmail_extra">--Jason Ekstrand<br></div></div>