<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 28, 2013 at 1:24 AM, Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Fri, 26 Apr 2013 09:48:19 -0500<br>
Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote:<br>
<br>
> Wayland Devs,<br>
><br>
> What follows is an idea that's been kicking around my head for a little<br>
> while now due to a discussion on the list a month or so ago.  The basic<br>
> idea is to add an interface that provides some additional buffer types that<br>
> don't have any back-end data of their own, but act as filters for other<br>
> buffers.<br>
><br>
> As you would expect, the interface would have an enum representing all of<br>
> the filters supported by the compositor and an event that would announce<br>
> all of the supported filters upon binding by the client.  Then, there would<br>
> be a series of "create_" requests that would take a new_id of type<br>
> wl_buffer (for the newly created filter), a object argument of type<br>
> wl_buffer for the buffer being wrapped, and possibly some other arguments<br>
> depending on the filter.  In theory, you could stack filters, but that<br>
> might get dicey and we would have to define some semantics for that.  I'm<br>
> sure there are more filters that would be useful, but here are a couple<br>
> that come to mind.<br>
><br>
> INVISIBLE<br>
><br>
> This is not really a filter.  Rather, it would be a buffer that has a size,<br>
> but no content whatsoever.  The compositor would know that the surface to<br>
> which this buffer is attached and, while it would be mapped onscreen would<br>
> never be rendered.<br>
><br>
> I can think of a few different possible uses for this (mostly having to do<br>
> with sub-ssurfaces).  For example, you could use an invisible buffer the<br>
> size of your entire window to catch all of the input events and then patch<br>
> the window together out of input-unaware subsurfaces.  I don't remember all<br>
> of the details of subsurfaces and input, but this seems useful to me.<br>
<br>
</div></div>I don't really like the idea of a shortcut invisible buffer. The<br>
problems you pointed out with sub-surfaces and the surface tree<br>
structure; I have started to think all those difficulties are due<br>
to not having a protocol object for a window. A window object could<br>
be just a container for wl_surfaces, without any of its own<br>
content, but adding that now would be too disruptive, I guess.<br><div class="im"></div></blockquote><div><br></div><div>I would like to see some sort of invisible surface for use with sub-surfaces as it makes the surface trees much nicer.  That said, there may be a better way to handle it than this.  Perhaps simply an extension of wl_surface that allows you to map with a particular size and no buffer.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> SCALE/ZOOM<br>
><br>
> This would create a buffer whose content is provided by another buffer but<br>
> has a different size.  The compositor would scale via GL or hardware<br>
> overlays.  We would probably need an additional argument for the type of<br>
> scaling (linear, cubic, etc.)<br>
><br>
> One possible use for this would be, for example, a video player.  A<br>
> standard DVD video is encoded at 720x480 but is *always* scaled (720x480 is<br>
> neither 16:9 or 4:3).  This would allow a media player to provide a 720x480<br>
> video stream at 24 or 30 FPS and then have the compositor scale it up to<br>
> 1920x1080 or whatever.  For fullscreen surfaces, this isn't a problem, but<br>
> if they have a non-fullscreen but still big window, the client currently<br>
> has to provide it at full resolution.<br>
><br>
> This has huge bandwidth advantages if the client is using wl_shm.  Also, it<br>
> would allow the compositor to use hardware overlays when available to do<br>
> the scaling which are (from what I know) more efficient and often provide<br>
> better scaling than a client will get even with GL.<br>
<br>
</div>FWIW, on Friday afternoon I already wrote half of the XML protocol<br>
spec for a crop & scale extension for wl_surfaces. The basic idea<br>
is similar to sub-surfaces and shell surfaces: a global factory,<br>
which you use to create an additional interface object for a<br>
wl_surface. This interface object then allows you to set the source<br>
rectangle to be read from a buffer, and destination size, which<br>
will become the surface size on the next commit.<br><div class="im"></div></blockquote><div><br></div><div>Perhaps this is something better handled at the surface level.  The primary reason why I was suggesting doing it with buffers is because, in the protocol, surfaces get their sizes from buffers.  That said, I'm eager to see (even just the XML) for your wl_surface method of handling it.  If we can make that work well, it very well may be cleaner particularly because you wouldn't need a stack of filter buffers for each buffer, you just need the one crop/scale for the surface.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> This is just a quick list of a couple ideas.  Perhaps more immediate<br>
> questions are, Is this useful? and, Is this too much of an abuse of<br>
> wl_buffer?<br>
<br>
</div>For the use cases you mentioned, I am sceptical. It would certainly<br>
be complex. For instance, as you have wl_buffers referencing other<br>
wl_buffers, how do you implement buffer releasing logic? The<br>
logical possibility of stacking you mentioned is also a problem: if<br>
it is not supported, do we need a non-fatal way to notify about it?<br>
If we do, that essentially becomes a roundtrip requirement: "did<br>
this operation succeed?"<br>
<br>
Right now, the wl_buffer reservance logic is fairly simple. A<br>
committed attach makes a wl_buffer reserved by the server, and when<br>
the server is guaranteed to not need the buffer anymore, it sends<br>
the release event. If we have wl_buffers referencing wl_buffers,<br>
when does a wl_buffer become reserved or released?<br></blockquote><div><br></div><div>Server-side, this would be as simple as reference counting.  On the client side, you're right that it gets more complicated.  In most use-cases where you have one buffer per surface, it would be exactly the same; you would simply recieve multiple events.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I would need to see more compelling use cases for your scheme to<br>
be able to support it.<br></blockquote><div><br></div><div>Right.  Stacking buffers provides a nice, theoretically simple, way to handle these types of things.  However, it does make for a lot of edge-cases in implementation.<br>
</div><br></div><div class="gmail_quote">Thanks,<br></div><div class="gmail_quote">--Jason Ekstrand<br></div></div></div>