[PATCH weston] compositor: add a layer clipping mechanism

[Pekka Paalanen]

On Tue, 23 Apr 2013 15:01:18 +0200
Giulio Camuffo <giuliocamuffo at gmail.com> wrote:

> 2013/4/23 Pekka Paalanen <ppaalanen at gmail.com>
> 
> > On Mon,  8 Apr 2013 14:31:53 +0200
> > Giulio Camuffo <giuliocamuffo at gmail.com> wrote:
> >
> > > this adds a mechanism to clip the surfaces belonging to a layer
> > > to an arbitrary rect
> >
> > Hi Giulio,
> >
> > I don't have anything against the idea of clipping layers, but the
> > implementation below is puzzling.
> >
> > > ---
> > >
> > > I'm using this functionality in my shell plugin
> > > (https://github.com/giucam/orbital/tree/workspaces) to implement
> > workspaces.
> > > See http://www.youtube.com/watch?v=_o-sKdyUPO8 for a screencast.
> > > As you see there i need to be able to show all the windows of all the
> > > workspaces, but clipped to their workspace, so they don't stick out over
> > > neighbour ones. So simply showing/hiding layers does not work.
> > >
> > >  src/compositor.c | 15 +++++++++++++++
> > >  src/compositor.h |  8 ++++++++
> > >  2 files changed, 23 insertions(+)
> > >
> > > diff --git a/src/compositor.c b/src/compositor.c
> > > index 3645b04..a748894 100644
> > > --- a/src/compositor.c
> > > +++ b/src/compositor.c
> > > @@ -1159,6 +1159,7 @@ surface_accumulate_damage(struct weston_surface
> > *surface,
> > >       pixman_region32_union(&surface->plane->damage,
> > >                             &surface->plane->damage, &surface->damage);
> > >       empty_region(&surface->damage);
> > > +     pixman_region32_subtract(opaque, &surface->transform.boundingbox,
> > &surface->layer->clip);
> >
> > So, you subtract layer.clip from the surface bounding box to produce
> > 'opaque'. Hmm... I don't really understand the set operations here. It
> > seems somehow inverted. What does layer.clip mean, is it the region
> > that is inside or outside of the paintable region?
> >
> > If layer.clip is the outside, i.e. the region to be clipped away, isn't
> > weston_layer_clip() then incapable of clipping from more than one side?
> >
> > Doesn't this subtracting into 'opaque' clobber the state that is being
> > accumulated into it over several calls to surface_accumulate_damage()?
> > 'opaque' is supposed to accumulate the opaque regions when walking the
> > surface stack from top to bottom, so we can skip painting surface
> > regions that are already hidden by opaque regions above. Simple
> > assignment to it is strange.
> >
> > Could you explain these operations, since to me they look just wrong?
> >
> 
> I don't fully understand how the repaint is done, and what e.g. the opaque
> region there is, so i may well have done some stupid mistake.
> layer->clip is a region outside of which any layer surface should be
> clipped, so it renders only what is inside that region. Maybe 'clip' isn't
> the right name, and e.g. 'visible' would be better.
> 

The name 'clip' is fine, I was just confused by the code there, where
it seemed to be used somehow inverted, but it was actually used doubly
inverted. No, wait... weston_surface::clip is the opposite, isn't it?
Ok, so the name needs to be changed, otherwise it's confusing. How about
'mask'?

The 'opaque' region in surface_accumulate_damage() is initialised
outside of the function to be initially empty. Then the function is
called for each surface in z-order, from top to bottom. First, the
previous 'opaque' is subtracted from the surface damage, so we do not
repaint it. Then, this surface's opaque region is added to 'opaque' for
the next call, so that what will be under the opaque regions of this
surface, will not be repainted of the below surfaces. I suspect you
broke this optimization. Maybe the repaint debug mode could visualize
it for you.

Btw. I guess you are relying on a grab to avoid picking surfaces from
their clipped areas? That is, you are not calling the pick functions
while layer clipping is in effect? Otherwise you need to fix the input
side, too.


Thanks,
pq