On 05/01/2013 02:16 AM, John Kåre Alsaker wrote:
On Tue, Apr 30, 2013 at 10:49 PM, Jason Ekstrand <ja...@jlekstrand.net
<mailto:ja...@jlekstrand.net>> wrote:
On Tue, Apr 30, 2013 at 2:29 PM, Bill Spitzak <spit...@gmail.com
<mailto:spit...@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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
