desktop-shell: How to enable really alpha blending of weston background?

[Pekka Paalanen]

On Sat, 12 Mar 2016 11:33:40 -0800
"Jasper St. Pierre" <jstpierre at mecheye.net> wrote:

> I have to bring this up, because it's not necessarily true. There's
> something you're missing. After working on embedded SoCs, I realize
> that a lot of them put the YUV video plane *behind* the main RGB
> plane. This allows them to do subtitles and OSD controls over the
> video without stacking it RGB -> YUV -> RGB, as you might imagine.

Oh my.

> Thankfully, some of these systems allow you to put the video on top of
> RGB, but not all. Some even just have two YUV planes (for
> picture-in-picture) and one RGB plane on top, not even a cursor plane.
> 
> On embedded systems where they have fullscreen control, they simply
> render alpha-graphics into the RGB window, and then stack a YUV plane
> behind it to blend against.
> 
> Wayland, in its current subsurface architecture, can't support this
> system, unfortunately. The best thing I could think of here was to
> have Wayland consider a punch-through when it sees a YUV plane stacked
> under an RGB one from the same client, and it knows the scanout is
> ARGB. But maybe that's too auto-magical.
> 
> I think that could work, but the implementation would need to be
> tricky about all the special cases, if we cared enough to make those
> work, e.g. surfaces under the punch-through need to be knocked out,
> but surfaces above can't be, since they're stacked on top. And that
> implies surfaces under the punch-through can't themselves use
> overlays, etc.

I don't think it should be *that* hard, but of course I'm only talking
from Weston implementation point of view.

Let's say the scenegraph has a bunch of arbitrary surfaces below and
above a particular YUV surface that would be nice to put in a separate
hw plane. This YUV-surface is also opaque, which is a requirement to
even consider underlay.

Weston goes through the surface stack from top to bottom, looking for
surfaces that could be put on overlays. It comes to the YUV-surface,
but there are already things on top of it, so it cannot be promoted to
an overlay. Seeing that using underlay is possible from DRM
perspective, it decides to put it on an underlay. Putting a surface in
an underlay requires adding an extra surface filled with RGBA (0,0,0,0)
color for the renderer to create a punch-through (or just set a flag in
the weston_view that this is a punch-through surface).

Weston continues going through the surface stack. If it finds another
YUV surface, the accumulated occlusions prevent it from going to
another underlay, perhaps. So the surface to plane assignment should
work.

Then the renderer flattens everything on the primary plane. Since the
punch-through placeholder surface is both opaque and filled with
(0,0,0,0), the renderer automatically creates the punch-through hole as
intended, not rendering anything from beneath it, and rendering
everything that may be on top of it.

It's obviously not trivial, but I think Weston already computes
most of the things needed to do this, like opaque and non-opaque
occlusions. What we are mainly missing is how to choose between overlay
and underlay. And of course implementing the underlay bits in practice.
We already have region checks to see if overlays can be used not just
for the topmost surfaces, and underlays would need their own similar
checks/accumulation.

I also don't see how which client gives which surface would affect
this. There is no reason that the thing on top of an YUV surface must be
from any particular client.

So I think Wayland does support this. It would be possible to implement
in Weston IMO. OTOH, I cannot imagine what we should add, remove or
change in the Wayland protocol to help underlay support in addition to
overlay support, even if we were not bound by stability requirements.

The biggest problem I see is that there may be (and are) several
different solutions for a scenegraph to be laid onto hw planes, and
choosing the optimal configuration is not easy. That, and creating a
test suite to make sure things actually work.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160314/c28c85fc/attachment.sig>