On 01/28/2014 06:36 PM, Giulio Camuffo wrote:
2014-01-28 Ander Conselvan de Oliveira <conselv...@gmail.com>:
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. The DRM
backend has support for sprite planes too, but it is disabled since it can't
work correctly without a patched kernel. You can try it (with a regular
kernel) by pressing mod-shift-space followed by 'v'. If you run
weston-simple-egl -o, you'll notice the clipping won't work when the surface
is in a sprite plane.
Given the points above, I believe it would be better to keep the information
related to clipping in the weston_view structure. That way the backend and
the renderer can be completely unaware of the existence of layers. The
clipping information can be propagated from the layers to the views in the
beginning of weston_output_repaint() and/or as part of
weston_view_update_transform().
What's the difference between using view->layer.mask or using
view->mask? I don't seen how the latter helps anything in any way.
Besides, if the mask is in the view it should be in view space, but
that means adding complexity for no real benefit.
What happens if you have a surface with subsurfaces in a layer with a
mask? The layer_link for a subsurface is not in any layers, and that
causes a crash with your patch.
My point was not about writing view->mask instead of view->layer.mask,
but that we need to handle all the complexities about clipping in
Weston's core. The list of views and the information contained in them
is enough for the renderers to produce the correct output. We should
avoid making them aware of layers and subsurfaces.
Cheers,
Ander
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
