<div dir="ltr"><div><div><div>Wayland Devs,<br><br></div>What follows is an idea that's been kicking around my head for a little while now due to a discussion on the list a month or so ago.  The basic idea is to add an interface that provides some additional buffer types that don't have any back-end data of their own, but act as filters for other buffers.<br>
<br>As you would expect, the interface would have an enum representing all of the filters supported by the compositor and an event that would announce all of the supported filters upon binding by the client.  Then, there would be a series of "create_" requests that would take a new_id of type wl_buffer (for the newly created filter), a object argument of type wl_buffer for the buffer being wrapped, and possibly some other arguments depending on the filter.  In theory, you could stack filters, but that might get dicey and we would have to define some semantics for that.  I'm sure there are more filters that would be useful, but here are a couple that come to mind.<br>
<br></div><div>INVISIBLE<br><br></div><div>This is not really a filter.  Rather, it would be a buffer that has a size, but no content whatsoever.  The compositor would know that the surface to which this buffer is attached and, while it would be mapped onscreen would never be rendered.<br>
<br>I can think of a few different possible uses for this (mostly having to do with sub-ssurfaces).  For example, you could use an invisible buffer the size of your entire window to catch all of the input events and then patch the window together out of input-unaware subsurfaces.  I don't remember all of the details of subsurfaces and input, but this seems useful to me.<br>
<br></div><div>SCALE/ZOOM<br><br></div><div>This would create a buffer whose content is provided by another buffer but has a different size.  The compositor would scale via GL or hardware overlays.  We would probably need an additional argument for the type of scaling (linear, cubic, etc.)<br>
<br></div><div>One possible use for this would be, for example, a video player.  A standard DVD video is encoded at 720x480 but is *always* scaled (720x480 is neither 16:9 or 4:3).  This would allow a media player to provide a 720x480 video stream at 24 or 30 FPS and then have the compositor scale it up to 1920x1080 or whatever.  For fullscreen surfaces, this isn't a problem, but if they have a non-fullscreen but still big window, the client currently has to provide it at full resolution.<br>
<br>This has huge bandwidth advantages if the client is using wl_shm.  Also, it would allow the compositor to use hardware overlays when available to do the scaling which are (from what I know) more efficient and often provide better scaling than a client will get even with GL.<br>
<br></div><div>This is just a quick list of a couple ideas.  Perhaps more immediate questions are, Is this useful? and, Is this too much of an abuse of wl_buffer?<br><br></div><div>Thanks,<br></div><div>--Jason Ekstrand<br>
</div></div></div>