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

[Pekka Paalanen]

On Tue, 10 Dec 2013 16:09:18 +0100
Giulio Camuffo <giuliocamuffo at gmail.com> wrote:

> 2013/12/10 Pekka Paalanen <ppaalanen at gmail.com>:
> > 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.
> 
> It is available in the renderers, as view->layer->mask.
> 
> >
> >> 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.
> 
> Mmh, i didn't think of clip as an optimization only, but I guess you
> may be right. If that's the case maybe I should modify directly the gl
> and pixman renderers to do the masking themselves instead of relying
> on clip.

I'm not sure you need to go that far. I'd be happy with just some
explicit comments in the code either near the mask field or
weston_view, that say that if a renderer does not honour damage and
clip regions, it must use mask etc. directly to produce correct results.

And say in the commit message, that the rpi-renderer does not implement
this. Maybe even add an XXX-comment in the rpi-renderer while at it.
That would be ok by me.

I don't think there is any way to formulate the mask code so that
rpi-renderer would not need modifications, right?

Or hmm... what about output region? Ah no, rpi-renderer uses
0,0 and weston_output::width,height.


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