New renderer features (Re: [PATCH 2/2] compositor: add a masking mechanism to weston_layer)

[Pekka Paalanen]

On Tue, 28 Jan 2014 18:21:40 +0200
Ander Conselvan de Oliveira <conselvan2 at gmail.com> wrote:

> On 01/27/2014 09:46 PM, Giulio Camuffo wrote:
> > this adds a mechanism to mask the views belonging to a layer
> > to an arbitrary rect, in the global space. The parts that don't fit
> > in that rect will be clipped away.
> > Implemented in the gl and pixman renderers only for now.
> > ---
> >   src/compositor.c      | 26 +++++++++++++++++++++++++-
> >   src/compositor.h      |  7 +++++++
> >   src/gl-renderer.c     |  4 ++++
> >   src/pixman-renderer.c |  4 ++++
> >   4 files changed, 40 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/compositor.c b/src/compositor.c
> > index 9a269e5..25068b8 100644
> 
> [...]
> 
> > diff --git a/src/gl-renderer.c b/src/gl-renderer.c
> > index 0e5afbe..899c280 100644
> > --- a/src/gl-renderer.c
> > +++ b/src/gl-renderer.c
> > @@ -521,6 +521,10 @@ draw_view(struct weston_view *ev, struct
> > weston_output *output, pixman_region32_intersect(&repaint,
> >   				  &ev->transform.boundingbox,
> > damage); pixman_region32_subtract(&repaint, &repaint, &ev->clip);
> > +	pixman_region32_t mask;
> > +	pixman_region32_init_with_extents(&mask,
> > &ev->layer_link.layer->mask);
> > +	pixman_region32_intersect(&repaint, &repaint, &mask);
> > +	pixman_region32_fini(&mask);
> 
> There are more things you need to consider in order to clip properly.
> 
> 1) Opaque region. This is used to avoid rendering obscured parts of 
> surfaces. In compositor_accumulate_damage(), a clip region for each 
> surface is determined as the union of the opaque regions of the
> surfaces on top of it. That way, the parts of the surface that are
> covered by other opaque content is not rendered.
> 
> You can see the effect of this relatively easily. Patch desktop-shell
> to set a clip for the workspace layer that is smaller than the
> screen. Then running Weston with the X11 backend (or just make sure
> you have a software rendered cursor), open a weston-terminal and move
> it so that it crosses the border of the clipped region. Then move the
> mouse over the region that should be part of the terminal but is
> clipped away. Notice how the background is not redrawn properly.
> 
> In order to fix this, the opaque region used for calculating the
> surface clip also needs to be clipped.
> 
> 2) Sprite planes. There's another path through which content can get
> to the screen. When a view is put on a sprite plane, it complete
> bypasses the renderer. During the repaint process, the core gives the
> backend a chance to move views to different planes. At that moment,
> the backend could configure the sprite plane to clip the surface or
> just decide to not to use a sprite plane for it. However, it needs
> the clipping information to make that decision.
> 
> If I understand correctly, the rpi backend relies heavily on planes.

Hi,

a tiny clarification: The rpi backend does not use weston_planes, but
it has its very own renderer, that exclusively uses the hardware planes
directly. So if a change is needed in the renderers, it will be needed
also in rpi-renderer.

If someone wants to add features that they do not want to or cannot
implement in the rpi-renderer, I hope they could do it with a capability
flag (e.g. surface rotation), and make Weston core simply not use the
feature if it is not available. I'm not sure how much sense that would
make in this particular case, though.

I think we should agree on some sort of policy wrt. to hw-dependent
renderers like rpi-renderer and adding new rendering features, since I
or Collabora cannot implement every new feature as they appear in the
generic renderers, and feature developers cannot be required to get an
RPi for testing. Also some features could be impossible to implement on
RPi.

Kristian?


Thanks,
pq