[PATCH v17 09/14] compositor-drm: Ignore occluded views

[Daniel Stone]

Hi,
On Tue, 10 Jul 2018 at 10:06, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Mon,  9 Jul 2018 14:23:15 +0100 Daniel Stone <daniels at collabora.com> wrote:
> > @@ -3302,6 +3319,9 @@ drm_output_propose_state(struct weston_output *output_base,
> >               if (next_plane == NULL)
> >                       next_plane = drm_output_prepare_cursor_view(state, ev);
> >
> > +             if (next_plane == NULL && !drm_view_is_opaque(ev))
> > +                     next_plane = primary;

As you noted here, we only promote fully opaque views.

> However, I noticed something else. drm_output_preprare_overlay_view()
> may work also for non-opaque views. Therefore we need to handle
> overlays as non-opaque or know if they actually are opaque.
>
> Why do we even toggle opaqueness by the plane assignment? Why not
> simply directly add the opaque region to occluded_region regardless of
> the assigned plane?
>
> weston_view::transform.opaque is there for that purpose.
>
> drm_view_is_opaque() requires the whole view to be opaque, but we don't
> actually need that for occluded_region. We should be able to do with
> the proper opaque region in global coordinates, so that an opaque
> sub-region of a view on a plane would be counted as occlusion.

At the moment the whole area must be opaque in order to be promoted to
a view. There is another, later, stage where we can begin to promote
non-opaque views, however that gets tricky. We need to make sure that
DRM's plane blending is in line with what we expect (it might be, but
I'm not immediately sure), and we also need to begin to take care of
stacking order. At the moment, scanout/primary strictly stacks at the
bottom (furthest from eye) and cursor at the top (closest to eye),
with all the overlay planes in between.

We currently ensure the stacking order is correct by only promoting
views which do not overlap each other to overlay planes. If we started
loosening that, so planes could overlap each other (opaque or not), we
need to be setting the 'zpos' property of planes, or picking the plane
in the correct zpos. This got rather difficult rather fast, so I
decided it was probably best not to roll it into the series. Fabien
and Benji from STM had an old patchset which did implement this, which
should be checked and resurrected once this all lands.

Cheers,
Daniel