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

[Giulio Camuffo]

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.

Thanks,
Giulio

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