Buffer Filters

[Jason Ekstrand]

Wayland Devs,

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.

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.

INVISIBLE

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.

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.

SCALE/ZOOM

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

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.

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.

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?

Thanks,
--Jason Ekstrand
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130426/49988b7f/attachment.html>