[PATCH weston] compositor: add a masking mechanism to weston_layer

[Pekka Paalanen]

On Tue, 10 Dec 2013 14:46:25 +0100
Giulio Camuffo <giuliocamuffo at gmail.com> wrote:

> But the visible region of a surface wouldn't be a rect minus a rect,
> but the intersection of two rects, which is always a rect as long as
> they are both axis aligned, and surface rotation isn't supported
> anyway by the rpi renderer, right? What's a rect minus a rect is the
> weston_view::clip region, which is not the visible part of the surface
> but the hidden part. So maybe having clip be the visible part would be
> better for the rpi renderer, but anyway layer masking could still be
> supported.

Ok, so it is a double-negation of the mask rect in the end. If we can
have the mask rect in the rpi-renderer with the view, then it is
implementable indeed.

> Still, this patch makes use of a mechanism already present in weston,
> and which the rpi renderer doesn't respect. So it is a problem in the
> rpi renderer or in the mechanism itself, not in the user of the
> mechanism, imho.

And IMHO, the clip regions are only informational for the renderer, as
it makes sense to compute and cache them in the common code. Not
authoritative. We cannot support arbitrary clip regions in the
rpi-renderer in any case.

In fact, couldn't the renderer simply ignore the clip and damage regions
completely, as long as they just paint everything from back to front,
and produce the exact same output?

To me it's just a same kind of optimization as the damage regions.


Thanks,
pq

> 2013/12/10 Pekka Paalanen <ppaalanen at gmail.com>:
> > On Tue, 10 Dec 2013 14:13:50 +0100
> > Giulio Camuffo <giuliocamuffo at gmail.com> wrote:
> >
> >> 2013/12/10 Pekka Paalanen <ppaalanen at gmail.com>:
> >> > On Tue, 10 Dec 2013 11:13:42 +0100
> >> > Giulio Camuffo <giuliocamuffo at gmail.com> wrote:
> >> >
> >> >> 2013/12/10 Jason Ekstrand <jason at jlekstrand.net>:
> >> >> > Giulio,
> >> >> > Couple thoughts.  First, you don't provide an implementation
> >> >> > of the clipping in  any of the renderers.  Probably have to
> >> >> > wait on the Collabora people for the RPi renderer, but we
> >> >> > should have pixman and gl implementations of this.
> >> >>
> >> >> There is no need to add support in the renderers for that. The
> >> >> masking is done in view_accumulate_damage(): the part of the
> >> >> view's boundingbox that doesn't fit in the mask is added to the
> >> >> view's clip, and the renderers then clip that away already.
> >> >
> >> > Does this work if the renderer paints the whole surface
> >> > regardless of damage? Rpi-renderer does that, since every
> >> > surface is on its own overlay.
> >> >
> >> > The whole damage tracking is kind of unused on the rpi-renderer,
> >> > since the firmware will probably redraw everything anyway.
> >> > Prohibiting damage will not prevent parts of a surface from being
> >> > painted. Damage is just a hint saying what is not necessary to
> >> > repaint.
> >>
> >> No, the masking isn't done by not damaging the parts not in the
> >> mask, but by adding the opposite of the mask in weston_view::clip.
> >> But i see that the rpi renderer doesn't clip away that, so no,
> >> currently this wouldn't work with it. I guess it could work
> >> though, right?
> >
> > We do not have arbitrary clip rectangles. We can only pick one
> > arbitrary but axis-aligned rectangle from within the buffer to map
> > onto the screen and that's it, just like your average overlay
> > hardware.
> >
> > We could do more complex clips by using one dispmanx element
> > (overlay) per rectangle of the final paint region, but that gets
> > complicated, and even though there can be many elements, they are
> > still a limited resource. I do not think this would be feasible.
> >
> > So if the surface can still be just a single rect on screen,
> > overlaid with other surfaces in the z-order, then it would be
> > possible. But I guess you'd have to separate occlusion clips from
> > mask clips. Note though, that a rect minus a rect is not in general
> > a rect but a region.
> >
> >
> > Thanks,
> > pq