sungmg/mutter-performance-source
1
0
Fork 0
Code Activity
mutter-performance-source/src/compositor/meta-surface-actor.c

560 lines
17 KiB
C
Raw Normal View History

Introduce MetaSurfaceActor for drawing MetaWindowActor content Instead of having MetaWindowActor only have one single MetaShapedTexture as actor drawing its content, introduce a new abstract MetaSurfaceActor that takes care of drawing. This is one step in the direction to decouple MetaWaylandSurface with a MetaWindow and MetaWindowActor (except for shell/xdg surfaces) in order to finally support subsurfaces like features, or any feature where window is not drawn using a single texture. The first step, implemented in this patch, is to not have MetaWindowActor work directly with a shaped texture. There are still some cases where it simply gets the texture and goes on as before, but this should be changed by either removing the need of going via MetaWindowActor or by adding some generic interface to MetaSurfaceActor that doesn't limit its functionality to one shaped texture. There should be no visible difference nor after this patch, but meta_window_actor_get_texture() and meta_surface_actor_get_texture() should be deprecated when equivalent functionality has been introduced. Signed-off-by: Jonas Ådahl <jadahl@gmail.com> https://bugzilla.gnome.org/show_bug.cgi?id=705502
2013-10-13 11:47:53 +00:00
/* -*- mode: C; c-file-style: "gnu"; indent-tabs-mode: nil; -*- */
/**
* SECTION:meta-surface-actor
* @title: MetaSurfaceActor
* @short_description: An actor representing a surface in the scene graph
*
Add some gtk-doc comments.
2018-10-19 07:15:54 +00:00
* MetaSurfaceActor is an abstract class which represents a surface in the
* Clutter scene graph. A subclass can implement the specifics of a surface
* depending on the way it is handled by a display protocol.
*
* An important feature of #MetaSurfaceActor is that it allows you to set an
* "input region": all events that occur in the surface, but outside of the
* input region are to be explicitly ignored. By default, this region is to
* %NULL, which means events on the whole surface is allowed.
Introduce MetaSurfaceActor for drawing MetaWindowActor content Instead of having MetaWindowActor only have one single MetaShapedTexture as actor drawing its content, introduce a new abstract MetaSurfaceActor that takes care of drawing. This is one step in the direction to decouple MetaWaylandSurface with a MetaWindow and MetaWindowActor (except for shell/xdg surfaces) in order to finally support subsurfaces like features, or any feature where window is not drawn using a single texture. The first step, implemented in this patch, is to not have MetaWindowActor work directly with a shaped texture. There are still some cases where it simply gets the texture and goes on as before, but this should be changed by either removing the need of going via MetaWindowActor or by adding some generic interface to MetaSurfaceActor that doesn't limit its functionality to one shaped texture. There should be no visible difference nor after this patch, but meta_window_actor_get_texture() and meta_surface_actor_get_texture() should be deprecated when equivalent functionality has been introduced. Signed-off-by: Jonas Ådahl <jadahl@gmail.com> https://bugzilla.gnome.org/show_bug.cgi?id=705502
2013-10-13 11:47:53 +00:00
*/
Clean up include macros mess The order and way include macros were structured was chaotic, with no real common thread between files. Try to tidy up the mess with some common scheme, to make things look less messy.
2018-07-10 08:36:24 +00:00
#include "config.h"
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
Clean up include macros mess The order and way include macros were structured was chaotic, with no real common thread between files. Try to tidy up the mess with some common scheme, to make things look less messy.
2018-07-10 08:36:24 +00:00
#include "compositor/meta-surface-actor.h"
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
Clean up include macros mess The order and way include macros were structured was chaotic, with no real common thread between files. Try to tidy up the mess with some common scheme, to make things look less messy.
2018-07-10 08:36:24 +00:00
#include "clutter/clutter.h"
surface-actor: Implement meta_cullable_is_untransformed interface Its `cull_out()` method was already implemented with geometry scale in mind. Add a corresponding `is_untransformed()` method so culling succeeds with geometry scale > 1. https://gitlab.gnome.org/GNOME/mutter/merge_requests/1036
2020-02-03 20:25:39 +00:00
#include "compositor/clutter-utils.h"
Clean up include macros mess The order and way include macros were structured was chaotic, with no real common thread between files. Try to tidy up the mess with some common scheme, to make things look less messy.
2018-07-10 08:36:24 +00:00
#include "compositor/meta-cullable.h"
#include "compositor/meta-shaped-texture-private.h"
window-actor: Handle geometry scale Geometry scale is applied to each surface individually, using Clutter scales, and not only this breaks subsurfaces, it also pollutes the toolkit and makes the actor tree slightly too fragile. If GNOME Shell mistakenly tries to set the actor scale of any of these surfaces, for example, various artifacts might happen. Move geometry scale handling to MetaWindowActor. It is applied as a child transform operation, so that the Clutter-managed scale properties are left untouched. In the future where the entirety of the window is managed by a ClutterContent itself, the geometry scale will be applied directly into the transform matrix of MetaWindowActor. However, doing that now would break the various ClutterClones used by GNOME Shell, so the child transform is an acceptable compromise during this transition. https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
2019-07-12 17:33:17 +00:00
#include "compositor/meta-window-actor-private.h"
wayland: Don't scale input and opaque regions Leave them at surface coordinates and let MetaSurfaceActor and MetaShapedTexture handle the interactions between buffer and geometry scale. https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
2019-07-12 16:56:14 +00:00
#include "compositor/region-utils.h"
Clean up include macros mess The order and way include macros were structured was chaotic, with no real common thread between files. Try to tidy up the mess with some common scheme, to make things look less messy.
2018-07-10 08:36:24 +00:00
#include "meta/meta-shaped-texture.h"
Introduce MetaSurfaceActor for drawing MetaWindowActor content Instead of having MetaWindowActor only have one single MetaShapedTexture as actor drawing its content, introduce a new abstract MetaSurfaceActor that takes care of drawing. This is one step in the direction to decouple MetaWaylandSurface with a MetaWindow and MetaWindowActor (except for shell/xdg surfaces) in order to finally support subsurfaces like features, or any feature where window is not drawn using a single texture. The first step, implemented in this patch, is to not have MetaWindowActor work directly with a shaped texture. There are still some cases where it simply gets the texture and goes on as before, but this should be changed by either removing the need of going via MetaWindowActor or by adding some generic interface to MetaSurfaceActor that doesn't limit its functionality to one shaped texture. There should be no visible difference nor after this patch, but meta_window_actor_get_texture() and meta_surface_actor_get_texture() should be deprecated when equivalent functionality has been introduced. Signed-off-by: Jonas Ådahl <jadahl@gmail.com> https://bugzilla.gnome.org/show_bug.cgi?id=705502
2013-10-13 11:47:53 +00:00
Use G_DECLARE_DERIVABLE/FINAL_TYPE on some types This is only for types in the `Meta` namespace. * Clears up a lot of boilerplate * We get `g_autoptr` support for free
2018-10-31 10:47:17 +00:00
typedef struct _MetaSurfaceActorPrivate
Introduce MetaSurfaceActor for drawing MetaWindowActor content Instead of having MetaWindowActor only have one single MetaShapedTexture as actor drawing its content, introduce a new abstract MetaSurfaceActor that takes care of drawing. This is one step in the direction to decouple MetaWaylandSurface with a MetaWindow and MetaWindowActor (except for shell/xdg surfaces) in order to finally support subsurfaces like features, or any feature where window is not drawn using a single texture. The first step, implemented in this patch, is to not have MetaWindowActor work directly with a shaped texture. There are still some cases where it simply gets the texture and goes on as before, but this should be changed by either removing the need of going via MetaWindowActor or by adding some generic interface to MetaSurfaceActor that doesn't limit its functionality to one shaped texture. There should be no visible difference nor after this patch, but meta_window_actor_get_texture() and meta_surface_actor_get_texture() should be deprecated when equivalent functionality has been introduced. Signed-off-by: Jonas Ådahl <jadahl@gmail.com> https://bugzilla.gnome.org/show_bug.cgi?id=705502
2013-10-13 11:47:53 +00:00
{
Revert "ff" This reverts commit 74462133ca7e85aabaac634517dbd5dd0a7742c2. Pushed by accident, if it wasn't obvious...
2013-11-19 16:22:49 +00:00
MetaShapedTexture *texture;
Fix the input region not working properly The input region was set on the shaped texture, but the shaped texture was never picked properly, as it was never set to be reactive. Move the pick implementation and reactivity to the MetaSurfaceActor, and update the code everywhere else to expect a MetaSurfaceActor.
2014-02-19 02:27:20 +00:00
cairo_region_t *input_region;
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
shaped-texture: Move MetaCullable helpers to MetaSurfaceActor Now that MetaShapedTexture is not a ClutterActor anymore, it does not make sense to make it a MetaCullable semi-implementation. This is, naturally, a responsibility of MetaSurfaceActor, since now MetaShapedTexture is a ClutterContent and as such, it only cares about what to draw. Move the MetaCullable implementation of MetaShapedTexture to MetaSurfaceActor. https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
2019-01-29 21:53:50 +00:00
/* MetaCullable regions, see that documentation for more details */
cairo_region_t *unobscured_region;
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
/* Freeze/thaw accounting */
surface-actor: Keep track of ignored damage We ignore all damage while a surface is frozen and queue a full update instead once it's thawed. While not super efficient, this isn't overly bad for the intended case of catching up with any updates that happened during a compositor effect. However when extended frame sync is used, surfaces are also frozen while the client is drawing a frame, in which case the current behavior is pretty damaging (pun intended), as we end up redrawing the entire window each frame. To address this, keep track of the actual damage we ignore and apply it when the surface is thawed. https://bugzilla.gnome.org/show_bug.cgi?id=767798
2016-06-17 15:45:20 +00:00
cairo_region_t *pending_damage;
MetaSurfaceActor: move freeze accounting to MetaWindowActor Turns out we only ever need to freeze/thaw whole windows, not surfaces or subsurfaces. This will allow removing the surface actor without losing the count.
2014-02-24 21:00:12 +00:00
guint frozen : 1;
Use G_DECLARE_DERIVABLE/FINAL_TYPE on some types This is only for types in the `Meta` namespace. * Clears up a lot of boilerplate * We get `g_autoptr` support for free
2018-10-31 10:47:17 +00:00
} MetaSurfaceActorPrivate;
Introduce MetaSurfaceActor for drawing MetaWindowActor content Instead of having MetaWindowActor only have one single MetaShapedTexture as actor drawing its content, introduce a new abstract MetaSurfaceActor that takes care of drawing. This is one step in the direction to decouple MetaWaylandSurface with a MetaWindow and MetaWindowActor (except for shell/xdg surfaces) in order to finally support subsurfaces like features, or any feature where window is not drawn using a single texture. The first step, implemented in this patch, is to not have MetaWindowActor work directly with a shaped texture. There are still some cases where it simply gets the texture and goes on as before, but this should be changed by either removing the need of going via MetaWindowActor or by adding some generic interface to MetaSurfaceActor that doesn't limit its functionality to one shaped texture. There should be no visible difference nor after this patch, but meta_window_actor_get_texture() and meta_surface_actor_get_texture() should be deprecated when equivalent functionality has been introduced. Signed-off-by: Jonas Ådahl <jadahl@gmail.com> https://bugzilla.gnome.org/show_bug.cgi?id=705502
2013-10-13 11:47:53 +00:00
shaped-texture: Make Cullable Make MetaWindowActor chain up to the generic default MetaCullable implementation, and remove the helper methods for MetaSurfaceActor and MetaShapedTexture.
2013-11-21 21:25:20 +00:00
static void cullable_iface_init (MetaCullableInterface *iface);
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
G_DEFINE_ABSTRACT_TYPE_WITH_CODE (MetaSurfaceActor, meta_surface_actor, CLUTTER_TYPE_ACTOR,
Stop using g_type_class_add_private() It is now deprecated in favor of the G_ADD_PRIVATE() macro (usually called via G_DEFINE_WITH_PRIVATE()). https://gitlab.gnome.org/GNOME/mutter/merge_requests/176
2018-07-19 11:40:39 +00:00
G_ADD_PRIVATE (MetaSurfaceActor)
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
G_IMPLEMENT_INTERFACE (META_TYPE_CULLABLE, cullable_iface_init));
Use a consistent style for enum braces https://gitlab.gnome.org/GNOME/mutter/merge_requests/361
2018-12-19 08:04:25 +00:00
enum
{
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
REPAINT_SCHEDULED,
window-actor: Rebuild the shape and mask when the surface updates Connecting to size-changed is wrong -- size-changed tells us when we *told* the X server or resize the window. For X11, we're sort of guaranteed that the surface will be updated at some point before the next frame, but for Xwayland, we can't be sure that the new surface is attached at this point. This fixes weird artifacts when resizing apps like xclock.
2014-07-31 09:05:34 +00:00
SIZE_CHANGED,
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
LAST_SIGNAL,
};
static guint signals[LAST_SIGNAL];
surface-actor: Move unobscured_region processing here https://bugzilla.gnome.org/show_bug.cgi?id=720631
2013-12-06 16:57:40 +00:00
surface-actor: Add culling offset for geometry scale - take 2 41130b08eb added a fix for culling subsurfaces with geometry scale. Unfortunately it only did so for the opaque regions, not for clip and unobscured regions, as the effect was hidden by bug that was only fixed by 3187fe8ebc7. Apply the same fix to clip and unobscured regions and use the chance to move most of the slightly hackish geometry scale related code into a single place. We need to scale slightly differently in the two cases, indicated by the new `ScalePerspectiveType` enum, as the scale is dependent on the perspective - once from outside, once from inside of the scaled actor. Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/1312
2020-06-28 21:56:21 +00:00
typedef enum
{
IN_STAGE_PERSPECTIVE,
IN_ACTOR_PERSPECTIVE
} ScalePerspectiveType;
shaped-texture: Move MetaCullable helpers to MetaSurfaceActor Now that MetaShapedTexture is not a ClutterActor anymore, it does not make sense to make it a MetaCullable semi-implementation. This is, naturally, a responsibility of MetaSurfaceActor, since now MetaShapedTexture is a ClutterContent and as such, it only cares about what to draw. Move the MetaCullable implementation of MetaShapedTexture to MetaSurfaceActor. https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
2019-01-29 21:53:50 +00:00
static cairo_region_t *
effective_unobscured_region (MetaSurfaceActor *surface_actor)
{
MetaSurfaceActorPrivate *priv =
meta_surface_actor_get_instance_private (surface_actor);
clutter/actor: Make has_mapped_clones() factor in parent actors All existing users of clutter_actor_has_mapped_clones() actually want to know whether the actor is being cloned by a visible clone, it doesn't matter to them if that clone is attached to an actor somewhere else in the tree or to the actor itself. So make clutter_actor_has_mapped_clones() a bit more convenient to use and also check the clones of the parent-actors in that function. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1235
2020-05-05 14:19:46 +00:00
ClutterActor *actor = CLUTTER_ACTOR (surface_actor);
shaped-texture: Move MetaCullable helpers to MetaSurfaceActor Now that MetaShapedTexture is not a ClutterActor anymore, it does not make sense to make it a MetaCullable semi-implementation. This is, naturally, a responsibility of MetaSurfaceActor, since now MetaShapedTexture is a ClutterContent and as such, it only cares about what to draw. Move the MetaCullable implementation of MetaShapedTexture to MetaSurfaceActor. https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
2019-01-29 21:53:50 +00:00
/* Fail if we have any mapped clones. */
clutter/actor: Make has_mapped_clones() factor in parent actors All existing users of clutter_actor_has_mapped_clones() actually want to know whether the actor is being cloned by a visible clone, it doesn't matter to them if that clone is attached to an actor somewhere else in the tree or to the actor itself. So make clutter_actor_has_mapped_clones() a bit more convenient to use and also check the clones of the parent-actors in that function. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1235
2020-05-05 14:19:46 +00:00
if (clutter_actor_has_mapped_clones (actor))
return NULL;
shaped-texture: Move MetaCullable helpers to MetaSurfaceActor Now that MetaShapedTexture is not a ClutterActor anymore, it does not make sense to make it a MetaCullable semi-implementation. This is, naturally, a responsibility of MetaSurfaceActor, since now MetaShapedTexture is a ClutterContent and as such, it only cares about what to draw. Move the MetaCullable implementation of MetaShapedTexture to MetaSurfaceActor. https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
2019-01-29 21:53:50 +00:00
return priv->unobscured_region;
}
static void
set_unobscured_region (MetaSurfaceActor *surface_actor,
cairo_region_t *unobscured_region)
{
MetaSurfaceActorPrivate *priv =
meta_surface_actor_get_instance_private (surface_actor);
g_clear_pointer (&priv->unobscured_region, cairo_region_destroy);
if (unobscured_region)
{
surface-actor: Do not copy empty clip/unobscured regions Clip and unobscured regions stricly shrink during culling. If they are already empty, simply reference the empty region to reduce allocations. https://gitlab.gnome.org/GNOME/mutter/merge_requests/1082
2020-02-25 18:59:22 +00:00
if (cairo_region_is_empty (unobscured_region))
{
priv->unobscured_region = cairo_region_reference (unobscured_region);
}
else
{
cairo_rectangle_int_t bounds = { 0, };
float width, height;
clutter_content_get_preferred_size (CLUTTER_CONTENT (priv->texture),
&width,
&height);
bounds = (cairo_rectangle_int_t) {
.width = width,
.height = height,
};
cullable: Generalize actor coordinates space translation for regions This allows MetaCullable to work with actors using arbitrary transforms which will be needed for implementing surface pixel alignment for fractional-scale-v1. This also deletes meta_cullable_is_untransformed as it's no longer necessary, and we can also stop manually scaling the region objects while performing opaque region culling in surfaces since it's now handled transparently by the new `meta_cullable_cull_out_children` implementation. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2726>
2023-04-07 15:19:34 +00:00
priv->unobscured_region = cairo_region_copy (unobscured_region);
surface-actor: Do not copy empty clip/unobscured regions Clip and unobscured regions stricly shrink during culling. If they are already empty, simply reference the empty region to reduce allocations. https://gitlab.gnome.org/GNOME/mutter/merge_requests/1082
2020-02-25 18:59:22 +00:00
cairo_region_intersect_rectangle (priv->unobscured_region, &bounds);
}
shaped-texture: Move MetaCullable helpers to MetaSurfaceActor Now that MetaShapedTexture is not a ClutterActor anymore, it does not make sense to make it a MetaCullable semi-implementation. This is, naturally, a responsibility of MetaSurfaceActor, since now MetaShapedTexture is a ClutterContent and as such, it only cares about what to draw. Move the MetaCullable implementation of MetaShapedTexture to MetaSurfaceActor. https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
2019-01-29 21:53:50 +00:00
}
}
static void
set_clip_region (MetaSurfaceActor *surface_actor,
cairo_region_t *clip_region)
{
MetaSurfaceActorPrivate *priv =
meta_surface_actor_get_instance_private (surface_actor);
shaped-texture: Reintroduce clip_region In commit 4c1fde9d MetaCullable related code was moved out of MetaShapedTexture into MetaSurfaceActor. While generally desirable, this removed drawing optimizations in MetaShapedTexture for partial redraws. The common case for fully obscured actors was still supposed to work, but it was now discovered that it actually did not. This commit revert parts of 4c1fde9d: it reintroduces clipping to MetaShapedTexture but leaves all culling and actor related logic in MetaSurfaceActor. Thanks to Daniel van Vugt for uncovering the issue. Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/850 Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1295 https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1326
2020-06-22 13:53:23 +00:00
MetaShapedTexture *stex = priv->texture;
shaped-texture: Move MetaCullable helpers to MetaSurfaceActor Now that MetaShapedTexture is not a ClutterActor anymore, it does not make sense to make it a MetaCullable semi-implementation. This is, naturally, a responsibility of MetaSurfaceActor, since now MetaShapedTexture is a ClutterContent and as such, it only cares about what to draw. Move the MetaCullable implementation of MetaShapedTexture to MetaSurfaceActor. https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
2019-01-29 21:53:50 +00:00
shaped-texture: Reintroduce clip_region In commit 4c1fde9d MetaCullable related code was moved out of MetaShapedTexture into MetaSurfaceActor. While generally desirable, this removed drawing optimizations in MetaShapedTexture for partial redraws. The common case for fully obscured actors was still supposed to work, but it was now discovered that it actually did not. This commit revert parts of 4c1fde9d: it reintroduces clipping to MetaShapedTexture but leaves all culling and actor related logic in MetaSurfaceActor. Thanks to Daniel van Vugt for uncovering the issue. Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/850 Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1295 https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1326
2020-06-22 13:53:23 +00:00
if (clip_region && !cairo_region_is_empty (clip_region))
surface-actor: Do not copy empty clip/unobscured regions Clip and unobscured regions stricly shrink during culling. If they are already empty, simply reference the empty region to reduce allocations. https://gitlab.gnome.org/GNOME/mutter/merge_requests/1082
2020-02-25 18:59:22 +00:00
{
cullable: Generalize actor coordinates space translation for regions This allows MetaCullable to work with actors using arbitrary transforms which will be needed for implementing surface pixel alignment for fractional-scale-v1. This also deletes meta_cullable_is_untransformed as it's no longer necessary, and we can also stop manually scaling the region objects while performing opaque region culling in surfaces since it's now handled transparently by the new `meta_cullable_cull_out_children` implementation. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2726>
2023-04-07 15:19:34 +00:00
cairo_region_t *clip_region_copy;
shaped-texture: Move MetaCullable helpers to MetaSurfaceActor Now that MetaShapedTexture is not a ClutterActor anymore, it does not make sense to make it a MetaCullable semi-implementation. This is, naturally, a responsibility of MetaSurfaceActor, since now MetaShapedTexture is a ClutterContent and as such, it only cares about what to draw. Move the MetaCullable implementation of MetaShapedTexture to MetaSurfaceActor. https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
2019-01-29 21:53:50 +00:00
cullable: Generalize actor coordinates space translation for regions This allows MetaCullable to work with actors using arbitrary transforms which will be needed for implementing surface pixel alignment for fractional-scale-v1. This also deletes meta_cullable_is_untransformed as it's no longer necessary, and we can also stop manually scaling the region objects while performing opaque region culling in surfaces since it's now handled transparently by the new `meta_cullable_cull_out_children` implementation. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2726>
2023-04-07 15:19:34 +00:00
clip_region_copy = cairo_region_copy (clip_region);
meta_shaped_texture_set_clip_region (stex, clip_region_copy);
shaped-texture: Move MetaCullable helpers to MetaSurfaceActor Now that MetaShapedTexture is not a ClutterActor anymore, it does not make sense to make it a MetaCullable semi-implementation. This is, naturally, a responsibility of MetaSurfaceActor, since now MetaShapedTexture is a ClutterContent and as such, it only cares about what to draw. Move the MetaCullable implementation of MetaShapedTexture to MetaSurfaceActor. https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
2019-01-29 21:53:50 +00:00
cullable: Generalize actor coordinates space translation for regions This allows MetaCullable to work with actors using arbitrary transforms which will be needed for implementing surface pixel alignment for fractional-scale-v1. This also deletes meta_cullable_is_untransformed as it's no longer necessary, and we can also stop manually scaling the region objects while performing opaque region culling in surfaces since it's now handled transparently by the new `meta_cullable_cull_out_children` implementation. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2726>
2023-04-07 15:19:34 +00:00
cairo_region_destroy (clip_region_copy);
shaped-texture: Reintroduce clip_region In commit 4c1fde9d MetaCullable related code was moved out of MetaShapedTexture into MetaSurfaceActor. While generally desirable, this removed drawing optimizations in MetaShapedTexture for partial redraws. The common case for fully obscured actors was still supposed to work, but it was now discovered that it actually did not. This commit revert parts of 4c1fde9d: it reintroduces clipping to MetaShapedTexture but leaves all culling and actor related logic in MetaSurfaceActor. Thanks to Daniel van Vugt for uncovering the issue. Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/850 Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1295 https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1326
2020-06-22 13:53:23 +00:00
}
else
{
meta_shaped_texture_set_clip_region (stex, clip_region);
}
shaped-texture: Move MetaCullable helpers to MetaSurfaceActor Now that MetaShapedTexture is not a ClutterActor anymore, it does not make sense to make it a MetaCullable semi-implementation. This is, naturally, a responsibility of MetaSurfaceActor, since now MetaShapedTexture is a ClutterContent and as such, it only cares about what to draw. Move the MetaCullable implementation of MetaShapedTexture to MetaSurfaceActor. https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
2019-01-29 21:53:50 +00:00
}
Fix the input region not working properly The input region was set on the shaped texture, but the shaped texture was never picked properly, as it was never set to be reactive. Move the pick implementation and reactivity to the MetaSurfaceActor, and update the code everywhere else to expect a MetaSurfaceActor.
2014-02-19 02:27:20 +00:00
static void
clutter: Introduce pick contexts Just as with painting, add a pick context that carries pick related temporary state when doing actor picking. It is currently unused, and will at least at first still carry around a framebuffer to deal track view transforms etc. https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
2019-11-20 20:46:41 +00:00
meta_surface_actor_pick (ClutterActor *actor,
ClutterPickContext *pick_context)
Fix the input region not working properly The input region was set on the shaped texture, but the shaped texture was never picked properly, as it was never set to be reactive. Move the pick implementation and reactivity to the MetaSurfaceActor, and update the code everywhere else to expect a MetaSurfaceActor.
2014-02-19 02:27:20 +00:00
{
MetaSurfaceActor *self = META_SURFACE_ACTOR (actor);
Use G_DECLARE_DERIVABLE/FINAL_TYPE on some types This is only for types in the `Meta` namespace. * Clears up a lot of boilerplate * We get `g_autoptr` support for free
2018-10-31 10:47:17 +00:00
MetaSurfaceActorPrivate *priv =
meta_surface_actor_get_instance_private (self);
compositor: Always recurse over surface children actors when picking The parent pick() implementation in ClutterActor only recurses if the vfunc is untouched, which means it's up to the MetaWaylandSurface implementation to actually recurse, just the same as if an input mask applied. https://bugzilla.gnome.org/show_bug.cgi?id=738890
2014-11-23 12:32:08 +00:00
ClutterActorIter iter;
ClutterActor *child;
Fix the input region not working properly The input region was set on the shaped texture, but the shaped texture was never picked properly, as it was never set to be reactive. Move the pick implementation and reactivity to the MetaSurfaceActor, and update the code everywhere else to expect a MetaSurfaceActor.
2014-02-19 02:27:20 +00:00
clutter/actor: Remove '_paint' suffix from clutter_actor_should_pick_paint We're not using paint to pick anymore. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1509
2020-10-16 13:06:39 +00:00
if (!clutter_actor_should_pick (actor, pick_context))
Fix the input region not working properly The input region was set on the shaped texture, but the shaped texture was never picked properly, as it was never set to be reactive. Move the pick implementation and reactivity to the MetaSurfaceActor, and update the code everywhere else to expect a MetaSurfaceActor.
2014-02-19 02:27:20 +00:00
return;
/* If there is no region then use the regular pick */
if (priv->input_region == NULL)
clutter: Introduce pick contexts Just as with painting, add a pick context that carries pick related temporary state when doing actor picking. It is currently unused, and will at least at first still carry around a framebuffer to deal track view transforms etc. https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
2019-11-20 20:46:41 +00:00
{
ClutterActorClass *actor_class =
CLUTTER_ACTOR_CLASS (meta_surface_actor_parent_class);
actor_class->pick (actor, pick_context);
}
Fix the input region not working properly The input region was set on the shaped texture, but the shaped texture was never picked properly, as it was never set to be reactive. Move the pick implementation and reactivity to the MetaSurfaceActor, and update the code everywhere else to expect a MetaSurfaceActor.
2014-02-19 02:27:20 +00:00
else
{
int n_rects;
int i;
n_rects = cairo_region_num_rectangles (priv->input_region);
for (i = 0; i < n_rects; i++)
{
cairo_rectangle_int_t rect;
clutter: Introduce geometric picking Currently, Clutter does picking by drawing with Cogl and reading the pixel that's beneath the given point. Since Cogl has a journal that records drawing operations, and has optimizations to read a single pixel from a list of rectangle, it would be expected that we would hit this fast path and not flush the journal while picking. However, that's not the case: dithering, clipping with scissors, etc, can all flush the journal, issuing commands to the GPU and making picking slow. On NVidia-based systems, this glReadPixels() call is extremely costly. Introduce geometric picking, and avoid using the Cogl journal entirely. Do this by introducing a stack of actors in ClutterStage. This stack is cached, but for now, don't use the cache as much as possible. The picking routines are still tied to painting. When projecting the actor vertexes, do it manually and take the modelview matrix of the framebuffer into account as well. CPU usage on an Intel i7-7700, tested with two different GPUs/drivers: | | Intel | Nvidia | | ------: | --------: | -----: | | Moving the mouse: | | Before | 10% | 10% | | After | 6% | 6% | | Moving a window: | | Before | 23% | 81% | | After | 19% | 40% | Closes: https://gitlab.gnome.org/GNOME/mutter/issues/154, https://gitlab.gnome.org/GNOME/mutter/issues/691 Helps significantly with: https://gitlab.gnome.org/GNOME/mutter/issues/283, https://gitlab.gnome.org/GNOME/mutter/issues/590, https://gitlab.gnome.org/GNOME/mutter/issues/700 v2: Fix code style issues Simplify quadrilateral checks Remove the 0.5f hack Differentiate axis-aligned rectangles https://gitlab.gnome.org/GNOME/mutter/merge_requests/189
2018-08-02 11:03:30 +00:00
ClutterActorBox box;
Fix the input region not working properly The input region was set on the shaped texture, but the shaped texture was never picked properly, as it was never set to be reactive. Move the pick implementation and reactivity to the MetaSurfaceActor, and update the code everywhere else to expect a MetaSurfaceActor.
2014-02-19 02:27:20 +00:00
cairo_region_get_rectangle (priv->input_region, i, &rect);
clutter: Introduce geometric picking Currently, Clutter does picking by drawing with Cogl and reading the pixel that's beneath the given point. Since Cogl has a journal that records drawing operations, and has optimizations to read a single pixel from a list of rectangle, it would be expected that we would hit this fast path and not flush the journal while picking. However, that's not the case: dithering, clipping with scissors, etc, can all flush the journal, issuing commands to the GPU and making picking slow. On NVidia-based systems, this glReadPixels() call is extremely costly. Introduce geometric picking, and avoid using the Cogl journal entirely. Do this by introducing a stack of actors in ClutterStage. This stack is cached, but for now, don't use the cache as much as possible. The picking routines are still tied to painting. When projecting the actor vertexes, do it manually and take the modelview matrix of the framebuffer into account as well. CPU usage on an Intel i7-7700, tested with two different GPUs/drivers: | | Intel | Nvidia | | ------: | --------: | -----: | | Moving the mouse: | | Before | 10% | 10% | | After | 6% | 6% | | Moving a window: | | Before | 23% | 81% | | After | 19% | 40% | Closes: https://gitlab.gnome.org/GNOME/mutter/issues/154, https://gitlab.gnome.org/GNOME/mutter/issues/691 Helps significantly with: https://gitlab.gnome.org/GNOME/mutter/issues/283, https://gitlab.gnome.org/GNOME/mutter/issues/590, https://gitlab.gnome.org/GNOME/mutter/issues/700 v2: Fix code style issues Simplify quadrilateral checks Remove the 0.5f hack Differentiate axis-aligned rectangles https://gitlab.gnome.org/GNOME/mutter/merge_requests/189
2018-08-02 11:03:30 +00:00
box.x1 = rect.x;
box.y1 = rect.y;
box.x2 = rect.x + rect.width;
box.y2 = rect.y + rect.height;
clutter: Introduce pick contexts Just as with painting, add a pick context that carries pick related temporary state when doing actor picking. It is currently unused, and will at least at first still carry around a framebuffer to deal track view transforms etc. https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
2019-11-20 20:46:41 +00:00
clutter_actor_pick_box (actor, pick_context, &box);
Fix the input region not working properly The input region was set on the shaped texture, but the shaped texture was never picked properly, as it was never set to be reactive. Move the pick implementation and reactivity to the MetaSurfaceActor, and update the code everywhere else to expect a MetaSurfaceActor.
2014-02-19 02:27:20 +00:00
}
compositor: Always recurse over surface children actors when picking The parent pick() implementation in ClutterActor only recurses if the vfunc is untouched, which means it's up to the MetaWaylandSurface implementation to actually recurse, just the same as if an input mask applied. https://bugzilla.gnome.org/show_bug.cgi?id=738890
2014-11-23 12:32:08 +00:00
}
compositor: Ensure child actors are included in picking If the actor surface has an input mask, custom picking is implemented for the portions affected by the mask, although the child actors (most usually subsurfaces) are left out. https://bugzilla.gnome.org/show_bug.cgi?id=738890
2014-10-20 16:44:55 +00:00
compositor: Always recurse over surface children actors when picking The parent pick() implementation in ClutterActor only recurses if the vfunc is untouched, which means it's up to the MetaWaylandSurface implementation to actually recurse, just the same as if an input mask applied. https://bugzilla.gnome.org/show_bug.cgi?id=738890
2014-11-23 12:32:08 +00:00
clutter_actor_iter_init (&iter, actor);
compositor: Ensure child actors are included in picking If the actor surface has an input mask, custom picking is implemented for the portions affected by the mask, although the child actors (most usually subsurfaces) are left out. https://bugzilla.gnome.org/show_bug.cgi?id=738890
2014-10-20 16:44:55 +00:00
compositor: Always recurse over surface children actors when picking The parent pick() implementation in ClutterActor only recurses if the vfunc is untouched, which means it's up to the MetaWaylandSurface implementation to actually recurse, just the same as if an input mask applied. https://bugzilla.gnome.org/show_bug.cgi?id=738890
2014-11-23 12:32:08 +00:00
while (clutter_actor_iter_next (&iter, &child))
clutter: Introduce pick contexts Just as with painting, add a pick context that carries pick related temporary state when doing actor picking. It is currently unused, and will at least at first still carry around a framebuffer to deal track view transforms etc. https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
2019-11-20 20:46:41 +00:00
clutter_actor_pick (child, pick_context);
Fix the input region not working properly The input region was set on the shaped texture, but the shaped texture was never picked properly, as it was never set to be reactive. Move the pick implementation and reactivity to the MetaSurfaceActor, and update the code everywhere else to expect a MetaSurfaceActor.
2014-02-19 02:27:20 +00:00
}
compositor: Add get_paint_volume() implementation to MetaSurfaceActor The special ::pick implementation there makes clutter fall into paths that do require a get_paint_volume() implementation, or an infinite area will be used. Providing a paint volume here is easier on the invalidation mechanism.
2018-04-28 16:14:34 +00:00
static gboolean
meta_surface_actor_get_paint_volume (ClutterActor *actor,
ClutterPaintVolume *volume)
{
return clutter_paint_volume_set_from_allocation (volume, actor);
}
Fix the input region not working properly The input region was set on the shaped texture, but the shaped texture was never picked properly, as it was never set to be reactive. Move the pick implementation and reactivity to the MetaSurfaceActor, and update the code everywhere else to expect a MetaSurfaceActor.
2014-02-19 02:27:20 +00:00
static void
meta_surface_actor_dispose (GObject *object)
{
MetaSurfaceActor *self = META_SURFACE_ACTOR (object);
Use G_DECLARE_DERIVABLE/FINAL_TYPE on some types This is only for types in the `Meta` namespace. * Clears up a lot of boilerplate * We get `g_autoptr` support for free
2018-10-31 10:47:17 +00:00
MetaSurfaceActorPrivate *priv =
meta_surface_actor_get_instance_private (self);
Fix the input region not working properly The input region was set on the shaped texture, but the shaped texture was never picked properly, as it was never set to be reactive. Move the pick implementation and reactivity to the MetaSurfaceActor, and update the code everywhere else to expect a MetaSurfaceActor.
2014-02-19 02:27:20 +00:00
g_clear_pointer (&priv->input_region, cairo_region_destroy);
surface-actor: Unref shaped texture on dispose The MetaShapedTexture created by MetaSurfaceActor used to be a ClutterActor, which means destruction was taken care by Clutter. Now that it's a plain GObject, we need to manually clean it up. Cleanup the shaped texture on disposal. https://gitlab.gnome.org/GNOME/mutter/merge_requests/753
2019-08-26 17:14:00 +00:00
g_clear_object (&priv->texture);
Fix the input region not working properly The input region was set on the shaped texture, but the shaped texture was never picked properly, as it was never set to be reactive. Move the pick implementation and reactivity to the MetaSurfaceActor, and update the code everywhere else to expect a MetaSurfaceActor.
2014-02-19 02:27:20 +00:00
shaped-texture: Move MetaCullable helpers to MetaSurfaceActor Now that MetaShapedTexture is not a ClutterActor anymore, it does not make sense to make it a MetaCullable semi-implementation. This is, naturally, a responsibility of MetaSurfaceActor, since now MetaShapedTexture is a ClutterContent and as such, it only cares about what to draw. Move the MetaCullable implementation of MetaShapedTexture to MetaSurfaceActor. https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
2019-01-29 21:53:50 +00:00
set_unobscured_region (self, NULL);
Fix the input region not working properly The input region was set on the shaped texture, but the shaped texture was never picked properly, as it was never set to be reactive. Move the pick implementation and reactivity to the MetaSurfaceActor, and update the code everywhere else to expect a MetaSurfaceActor.
2014-02-19 02:27:20 +00:00
G_OBJECT_CLASS (meta_surface_actor_parent_class)->dispose (object);
}
Introduce MetaSurfaceActor for drawing MetaWindowActor content Instead of having MetaWindowActor only have one single MetaShapedTexture as actor drawing its content, introduce a new abstract MetaSurfaceActor that takes care of drawing. This is one step in the direction to decouple MetaWaylandSurface with a MetaWindow and MetaWindowActor (except for shell/xdg surfaces) in order to finally support subsurfaces like features, or any feature where window is not drawn using a single texture. The first step, implemented in this patch, is to not have MetaWindowActor work directly with a shaped texture. There are still some cases where it simply gets the texture and goes on as before, but this should be changed by either removing the need of going via MetaWindowActor or by adding some generic interface to MetaSurfaceActor that doesn't limit its functionality to one shaped texture. There should be no visible difference nor after this patch, but meta_window_actor_get_texture() and meta_surface_actor_get_texture() should be deprecated when equivalent functionality has been introduced. Signed-off-by: Jonas Ådahl <jadahl@gmail.com> https://bugzilla.gnome.org/show_bug.cgi?id=705502
2013-10-13 11:47:53 +00:00
static void
meta_surface_actor_class_init (MetaSurfaceActorClass *klass)
{
Fix the input region not working properly The input region was set on the shaped texture, but the shaped texture was never picked properly, as it was never set to be reactive. Move the pick implementation and reactivity to the MetaSurfaceActor, and update the code everywhere else to expect a MetaSurfaceActor.
2014-02-19 02:27:20 +00:00
GObjectClass *object_class = G_OBJECT_CLASS (klass);
ClutterActorClass *actor_class = CLUTTER_ACTOR_CLASS (klass);
object_class->dispose = meta_surface_actor_dispose;
actor_class->pick = meta_surface_actor_pick;
compositor: Add get_paint_volume() implementation to MetaSurfaceActor The special ::pick implementation there makes clutter fall into paths that do require a get_paint_volume() implementation, or an infinite area will be used. Providing a paint volume here is easier on the invalidation mechanism.
2018-04-28 16:14:34 +00:00
actor_class->get_paint_volume = meta_surface_actor_get_paint_volume;
Fix the input region not working properly The input region was set on the shaped texture, but the shaped texture was never picked properly, as it was never set to be reactive. Move the pick implementation and reactivity to the MetaSurfaceActor, and update the code everywhere else to expect a MetaSurfaceActor.
2014-02-19 02:27:20 +00:00
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
signals[REPAINT_SCHEDULED] = g_signal_new ("repaint-scheduled",
G_TYPE_FROM_CLASS (object_class),
G_SIGNAL_RUN_LAST,
0,
NULL, NULL, NULL,
G_TYPE_NONE, 0);
window-actor: Rebuild the shape and mask when the surface updates Connecting to size-changed is wrong -- size-changed tells us when we *told* the X server or resize the window. For X11, we're sort of guaranteed that the surface will be updated at some point before the next frame, but for Xwayland, we can't be sure that the new surface is attached at this point. This fixes weird artifacts when resizing apps like xclock.
2014-07-31 09:05:34 +00:00
signals[SIZE_CHANGED] = g_signal_new ("size-changed",
G_TYPE_FROM_CLASS (object_class),
G_SIGNAL_RUN_LAST,
0,
NULL, NULL, NULL,
G_TYPE_NONE, 0);
Introduce MetaSurfaceActor for drawing MetaWindowActor content Instead of having MetaWindowActor only have one single MetaShapedTexture as actor drawing its content, introduce a new abstract MetaSurfaceActor that takes care of drawing. This is one step in the direction to decouple MetaWaylandSurface with a MetaWindow and MetaWindowActor (except for shell/xdg surfaces) in order to finally support subsurfaces like features, or any feature where window is not drawn using a single texture. The first step, implemented in this patch, is to not have MetaWindowActor work directly with a shaped texture. There are still some cases where it simply gets the texture and goes on as before, but this should be changed by either removing the need of going via MetaWindowActor or by adding some generic interface to MetaSurfaceActor that doesn't limit its functionality to one shaped texture. There should be no visible difference nor after this patch, but meta_window_actor_get_texture() and meta_surface_actor_get_texture() should be deprecated when equivalent functionality has been introduced. Signed-off-by: Jonas Ådahl <jadahl@gmail.com> https://bugzilla.gnome.org/show_bug.cgi?id=705502
2013-10-13 11:47:53 +00:00
}
window-actor: Move shapes, shadows and unredirection to X11 sub types Move out updating of various shapes (input, opaque, shape) indirectly from X11 to the corresponding X11 sub types of MetaWindowActor and MetaSurfaceActor. Also move fullscreen window unredirection code with it. We want to effectively do something similar for MetaCompositorServer, but it will work differently enough not to share too much logic. While it would have been nice to move things piece by piece, things were too intertwined to make it feasible. This has the side effect fixing accidentally and arbitrarily adding server side shadow to Wayland surfaces. Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/727 https://gitlab.gnome.org/GNOME/mutter/merge_requests/734
2019-08-17 08:00:46 +00:00
gboolean
meta_surface_actor_is_opaque (MetaSurfaceActor *self)
{
return META_SURFACE_ACTOR_GET_CLASS (self)->is_opaque (self);
}
shaped-texture: Make Cullable Make MetaWindowActor chain up to the generic default MetaCullable implementation, and remove the helper methods for MetaSurfaceActor and MetaShapedTexture.
2013-11-21 21:25:20 +00:00
static void
meta_surface_actor_cull_out (MetaCullable *cullable,
surface-actor: Reindent
2013-12-07 01:28:39 +00:00
cairo_region_t *unobscured_region,
cairo_region_t *clip_region)
shaped-texture: Make Cullable Make MetaWindowActor chain up to the generic default MetaCullable implementation, and remove the helper methods for MetaSurfaceActor and MetaShapedTexture.
2013-11-21 21:25:20 +00:00
{
shaped-texture: Implement ClutterContent MetaWindowActor is the compositor-side representative of a MetaWindow. Specifically it represents the geometry of the window under Clutter scene graph. MetaWindowActors are backed by MetaSurfaceActors, that represent the windowing system's surfaces themselves. Naturally, these surfaces have textures with the pixel content of the clients associated with them. These textures are represented by MetaShapedTexture. MetaShapedTextures are currently implemented as ClutterActor subclasses that override the paint function to paint the textures it holds. Conceptually, however, Clutter has an abstraction layer for contents of actors: ClutterContent. Which MetaShapedTexture fits nicely, in fact. Make MetaShapedTexture a ClutterContent implementation. This forces a few changes in the stack: * MetaShapedTexture now handles buffer scale. * We now paint into ClutterPaintNode instead of the direct framebuffer. * Various pieces of Wayland code now use MetaSurfaceActor instead of MetaShapedTexture. * MetaSurfaceActorWayland doesn't override size negotiation vfuncs anymore https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
2018-12-26 15:41:26 +00:00
MetaSurfaceActor *surface_actor = META_SURFACE_ACTOR (cullable);
MetaSurfaceActorPrivate *priv =
meta_surface_actor_get_instance_private (surface_actor);
uint8_t opacity = clutter_actor_get_opacity (CLUTTER_ACTOR (cullable));
shaped-texture: Move MetaCullable helpers to MetaSurfaceActor Now that MetaShapedTexture is not a ClutterActor anymore, it does not make sense to make it a MetaCullable semi-implementation. This is, naturally, a responsibility of MetaSurfaceActor, since now MetaShapedTexture is a ClutterContent and as such, it only cares about what to draw. Move the MetaCullable implementation of MetaShapedTexture to MetaSurfaceActor. https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
2019-01-29 21:53:50 +00:00
set_unobscured_region (surface_actor, unobscured_region);
set_clip_region (surface_actor, clip_region);
if (opacity == 0xff)
{
cairo_region_t *opaque_region;
opaque_region = meta_shaped_texture_get_opaque_region (priv->texture);
surface-actor: Cull out surfaces without alpha channel If a opaque region is explicitly set we should not consider the surface opaque, as that implies e.g. a shape region is set. If no opque region is set but the texture does not have an alpha channel, we can savely cull it out. https://gitlab.gnome.org/GNOME/mutter/merge_requests/1082
2020-02-23 15:37:50 +00:00
surface-actor: Simplify culling logic This reverts the commits 372d73e2757 and 1d2004524728 - the special case for alpha-less textures could only happen on Wayland, but now the opaque region is also set in those cases. This commit saves us some allocations, simplifies the logic a bit and makes sure culling uses the same opaque region as our painting paths. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1463
2020-09-30 23:38:16 +00:00
if (!opaque_region)
return;
wayland: Don't scale input and opaque regions Leave them at surface coordinates and let MetaSurfaceActor and MetaShapedTexture handle the interactions between buffer and geometry scale. https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
2019-07-12 16:56:14 +00:00
if (unobscured_region)
cullable: Generalize actor coordinates space translation for regions This allows MetaCullable to work with actors using arbitrary transforms which will be needed for implementing surface pixel alignment for fractional-scale-v1. This also deletes meta_cullable_is_untransformed as it's no longer necessary, and we can also stop manually scaling the region objects while performing opaque region culling in surfaces since it's now handled transparently by the new `meta_cullable_cull_out_children` implementation. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2726>
2023-04-07 15:19:34 +00:00
cairo_region_subtract (unobscured_region, opaque_region);
wayland: Don't scale input and opaque regions Leave them at surface coordinates and let MetaSurfaceActor and MetaShapedTexture handle the interactions between buffer and geometry scale. https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
2019-07-12 16:56:14 +00:00
if (clip_region)
cullable: Generalize actor coordinates space translation for regions This allows MetaCullable to work with actors using arbitrary transforms which will be needed for implementing surface pixel alignment for fractional-scale-v1. This also deletes meta_cullable_is_untransformed as it's no longer necessary, and we can also stop manually scaling the region objects while performing opaque region culling in surfaces since it's now handled transparently by the new `meta_cullable_cull_out_children` implementation. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2726>
2023-04-07 15:19:34 +00:00
cairo_region_subtract (clip_region, opaque_region);
shaped-texture: Move MetaCullable helpers to MetaSurfaceActor Now that MetaShapedTexture is not a ClutterActor anymore, it does not make sense to make it a MetaCullable semi-implementation. This is, naturally, a responsibility of MetaSurfaceActor, since now MetaShapedTexture is a ClutterContent and as such, it only cares about what to draw. Move the MetaCullable implementation of MetaShapedTexture to MetaSurfaceActor. https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
2019-01-29 21:53:50 +00:00
}
shaped-texture: Make Cullable Make MetaWindowActor chain up to the generic default MetaCullable implementation, and remove the helper methods for MetaSurfaceActor and MetaShapedTexture.
2013-11-21 21:25:20 +00:00
}
static void
meta_surface_actor_reset_culling (MetaCullable *cullable)
{
shaped-texture: Implement ClutterContent MetaWindowActor is the compositor-side representative of a MetaWindow. Specifically it represents the geometry of the window under Clutter scene graph. MetaWindowActors are backed by MetaSurfaceActors, that represent the windowing system's surfaces themselves. Naturally, these surfaces have textures with the pixel content of the clients associated with them. These textures are represented by MetaShapedTexture. MetaShapedTextures are currently implemented as ClutterActor subclasses that override the paint function to paint the textures it holds. Conceptually, however, Clutter has an abstraction layer for contents of actors: ClutterContent. Which MetaShapedTexture fits nicely, in fact. Make MetaShapedTexture a ClutterContent implementation. This forces a few changes in the stack: * MetaShapedTexture now handles buffer scale. * We now paint into ClutterPaintNode instead of the direct framebuffer. * Various pieces of Wayland code now use MetaSurfaceActor instead of MetaShapedTexture. * MetaSurfaceActorWayland doesn't override size negotiation vfuncs anymore https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
2018-12-26 15:41:26 +00:00
MetaSurfaceActor *surface_actor = META_SURFACE_ACTOR (cullable);
shaped-texture: Move MetaCullable helpers to MetaSurfaceActor Now that MetaShapedTexture is not a ClutterActor anymore, it does not make sense to make it a MetaCullable semi-implementation. This is, naturally, a responsibility of MetaSurfaceActor, since now MetaShapedTexture is a ClutterContent and as such, it only cares about what to draw. Move the MetaCullable implementation of MetaShapedTexture to MetaSurfaceActor. https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
2019-01-29 21:53:50 +00:00
set_clip_region (surface_actor, NULL);
shaped-texture: Make Cullable Make MetaWindowActor chain up to the generic default MetaCullable implementation, and remove the helper methods for MetaSurfaceActor and MetaShapedTexture.
2013-11-21 21:25:20 +00:00
}
static void
cullable_iface_init (MetaCullableInterface *iface)
{
iface->cull_out = meta_surface_actor_cull_out;
iface->reset_culling = meta_surface_actor_reset_culling;
}
window-actor: Rebuild the shape and mask when the surface updates Connecting to size-changed is wrong -- size-changed tells us when we *told* the X server or resize the window. For X11, we're sort of guaranteed that the surface will be updated at some point before the next frame, but for Xwayland, we can't be sure that the new surface is attached at this point. This fixes weird artifacts when resizing apps like xclock.
2014-07-31 09:05:34 +00:00
static void
texture_size_changed (MetaShapedTexture *texture,
gpointer user_data)
{
MetaSurfaceActor *actor = META_SURFACE_ACTOR (user_data);
g_signal_emit (actor, signals[SIZE_CHANGED], 0);
}
Introduce MetaSurfaceActor for drawing MetaWindowActor content Instead of having MetaWindowActor only have one single MetaShapedTexture as actor drawing its content, introduce a new abstract MetaSurfaceActor that takes care of drawing. This is one step in the direction to decouple MetaWaylandSurface with a MetaWindow and MetaWindowActor (except for shell/xdg surfaces) in order to finally support subsurfaces like features, or any feature where window is not drawn using a single texture. The first step, implemented in this patch, is to not have MetaWindowActor work directly with a shaped texture. There are still some cases where it simply gets the texture and goes on as before, but this should be changed by either removing the need of going via MetaWindowActor or by adding some generic interface to MetaSurfaceActor that doesn't limit its functionality to one shaped texture. There should be no visible difference nor after this patch, but meta_window_actor_get_texture() and meta_surface_actor_get_texture() should be deprecated when equivalent functionality has been introduced. Signed-off-by: Jonas Ådahl <jadahl@gmail.com> https://bugzilla.gnome.org/show_bug.cgi?id=705502
2013-10-13 11:47:53 +00:00
static void
meta_surface_actor_init (MetaSurfaceActor *self)
{
Use G_DECLARE_DERIVABLE/FINAL_TYPE on some types This is only for types in the `Meta` namespace. * Clears up a lot of boilerplate * We get `g_autoptr` support for free
2018-10-31 10:47:17 +00:00
MetaSurfaceActorPrivate *priv =
meta_surface_actor_get_instance_private (self);
Introduce MetaSurfaceActor for drawing MetaWindowActor content Instead of having MetaWindowActor only have one single MetaShapedTexture as actor drawing its content, introduce a new abstract MetaSurfaceActor that takes care of drawing. This is one step in the direction to decouple MetaWaylandSurface with a MetaWindow and MetaWindowActor (except for shell/xdg surfaces) in order to finally support subsurfaces like features, or any feature where window is not drawn using a single texture. The first step, implemented in this patch, is to not have MetaWindowActor work directly with a shaped texture. There are still some cases where it simply gets the texture and goes on as before, but this should be changed by either removing the need of going via MetaWindowActor or by adding some generic interface to MetaSurfaceActor that doesn't limit its functionality to one shaped texture. There should be no visible difference nor after this patch, but meta_window_actor_get_texture() and meta_surface_actor_get_texture() should be deprecated when equivalent functionality has been introduced. Signed-off-by: Jonas Ådahl <jadahl@gmail.com> https://bugzilla.gnome.org/show_bug.cgi?id=705502
2013-10-13 11:47:53 +00:00
shaped-texture: Implement ClutterContent MetaWindowActor is the compositor-side representative of a MetaWindow. Specifically it represents the geometry of the window under Clutter scene graph. MetaWindowActors are backed by MetaSurfaceActors, that represent the windowing system's surfaces themselves. Naturally, these surfaces have textures with the pixel content of the clients associated with them. These textures are represented by MetaShapedTexture. MetaShapedTextures are currently implemented as ClutterActor subclasses that override the paint function to paint the textures it holds. Conceptually, however, Clutter has an abstraction layer for contents of actors: ClutterContent. Which MetaShapedTexture fits nicely, in fact. Make MetaShapedTexture a ClutterContent implementation. This forces a few changes in the stack: * MetaShapedTexture now handles buffer scale. * We now paint into ClutterPaintNode instead of the direct framebuffer. * Various pieces of Wayland code now use MetaSurfaceActor instead of MetaShapedTexture. * MetaSurfaceActorWayland doesn't override size negotiation vfuncs anymore https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
2018-12-26 15:41:26 +00:00
priv->texture = meta_shaped_texture_new ();
window-actor: Rebuild the shape and mask when the surface updates Connecting to size-changed is wrong -- size-changed tells us when we *told* the X server or resize the window. For X11, we're sort of guaranteed that the surface will be updated at some point before the next frame, but for Xwayland, we can't be sure that the new surface is attached at this point. This fixes weird artifacts when resizing apps like xclock.
2014-07-31 09:05:34 +00:00
g_signal_connect_object (priv->texture, "size-changed",
G_CALLBACK (texture_size_changed), self, 0);
shaped-texture: Implement ClutterContent MetaWindowActor is the compositor-side representative of a MetaWindow. Specifically it represents the geometry of the window under Clutter scene graph. MetaWindowActors are backed by MetaSurfaceActors, that represent the windowing system's surfaces themselves. Naturally, these surfaces have textures with the pixel content of the clients associated with them. These textures are represented by MetaShapedTexture. MetaShapedTextures are currently implemented as ClutterActor subclasses that override the paint function to paint the textures it holds. Conceptually, however, Clutter has an abstraction layer for contents of actors: ClutterContent. Which MetaShapedTexture fits nicely, in fact. Make MetaShapedTexture a ClutterContent implementation. This forces a few changes in the stack: * MetaShapedTexture now handles buffer scale. * We now paint into ClutterPaintNode instead of the direct framebuffer. * Various pieces of Wayland code now use MetaSurfaceActor instead of MetaShapedTexture. * MetaSurfaceActorWayland doesn't override size negotiation vfuncs anymore https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
2018-12-26 15:41:26 +00:00
clutter_actor_set_content (CLUTTER_ACTOR (self),
CLUTTER_CONTENT (priv->texture));
clutter_actor_set_request_mode (CLUTTER_ACTOR (self),
CLUTTER_REQUEST_CONTENT_SIZE);
Introduce MetaSurfaceActor for drawing MetaWindowActor content Instead of having MetaWindowActor only have one single MetaShapedTexture as actor drawing its content, introduce a new abstract MetaSurfaceActor that takes care of drawing. This is one step in the direction to decouple MetaWaylandSurface with a MetaWindow and MetaWindowActor (except for shell/xdg surfaces) in order to finally support subsurfaces like features, or any feature where window is not drawn using a single texture. The first step, implemented in this patch, is to not have MetaWindowActor work directly with a shaped texture. There are still some cases where it simply gets the texture and goes on as before, but this should be changed by either removing the need of going via MetaWindowActor or by adding some generic interface to MetaSurfaceActor that doesn't limit its functionality to one shaped texture. There should be no visible difference nor after this patch, but meta_window_actor_get_texture() and meta_surface_actor_get_texture() should be deprecated when equivalent functionality has been introduced. Signed-off-by: Jonas Ådahl <jadahl@gmail.com> https://bugzilla.gnome.org/show_bug.cgi?id=705502
2013-10-13 11:47:53 +00:00
}
MetaShapedTexture *
meta_surface_actor_get_texture (MetaSurfaceActor *self)
{
Use G_DECLARE_DERIVABLE/FINAL_TYPE on some types This is only for types in the `Meta` namespace. * Clears up a lot of boilerplate * We get `g_autoptr` support for free
2018-10-31 10:47:17 +00:00
MetaSurfaceActorPrivate *priv =
meta_surface_actor_get_instance_private (self);
return priv->texture;
Introduce MetaSurfaceActor for drawing MetaWindowActor content Instead of having MetaWindowActor only have one single MetaShapedTexture as actor drawing its content, introduce a new abstract MetaSurfaceActor that takes care of drawing. This is one step in the direction to decouple MetaWaylandSurface with a MetaWindow and MetaWindowActor (except for shell/xdg surfaces) in order to finally support subsurfaces like features, or any feature where window is not drawn using a single texture. The first step, implemented in this patch, is to not have MetaWindowActor work directly with a shaped texture. There are still some cases where it simply gets the texture and goes on as before, but this should be changed by either removing the need of going via MetaWindowActor or by adding some generic interface to MetaSurfaceActor that doesn't limit its functionality to one shaped texture. There should be no visible difference nor after this patch, but meta_window_actor_get_texture() and meta_surface_actor_get_texture() should be deprecated when equivalent functionality has been introduced. Signed-off-by: Jonas Ådahl <jadahl@gmail.com> https://bugzilla.gnome.org/show_bug.cgi?id=705502
2013-10-13 11:47:53 +00:00
}
surface-actor: Move out some X11-ism to X11 subclass On X11 we don't update the texture in certain circumstances, such as if the surface is a fullscreen unredirect, or doesn't have a Pixmap. On Wayland we only want to avoid updating the texture if there is no texture, but as this is handled implicitly by MetashapedTexture, we don't need to try to emulate the X11-y conditions in the generic layer and instead just have the implementations handle update processing themself. This doesn't have any functional changes, but removes a vfunc from MetaSurfaceActorClass. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1218
2020-04-24 21:21:26 +00:00
void
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
meta_surface_actor_update_area (MetaSurfaceActor *self,
surface-actor: Move out some X11-ism to X11 subclass On X11 we don't update the texture in certain circumstances, such as if the surface is a fullscreen unredirect, or doesn't have a Pixmap. On Wayland we only want to avoid updating the texture if there is no texture, but as this is handled implicitly by MetashapedTexture, we don't need to try to emulate the X11-y conditions in the generic layer and instead just have the implementations handle update processing themself. This doesn't have any functional changes, but removes a vfunc from MetaSurfaceActorClass. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1218
2020-04-24 21:21:26 +00:00
int x,
int y,
int width,
int height)
surface-actor: Move unobscured_region processing here https://bugzilla.gnome.org/show_bug.cgi?id=720631
2013-12-06 16:57:40 +00:00
{
Use G_DECLARE_DERIVABLE/FINAL_TYPE on some types This is only for types in the `Meta` namespace. * Clears up a lot of boilerplate * We get `g_autoptr` support for free
2018-10-31 10:47:17 +00:00
MetaSurfaceActorPrivate *priv =
meta_surface_actor_get_instance_private (self);
shaped-texture: Move MetaCullable helpers to MetaSurfaceActor Now that MetaShapedTexture is not a ClutterActor anymore, it does not make sense to make it a MetaCullable semi-implementation. This is, naturally, a responsibility of MetaSurfaceActor, since now MetaShapedTexture is a ClutterContent and as such, it only cares about what to draw. Move the MetaCullable implementation of MetaShapedTexture to MetaSurfaceActor. https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
2019-01-29 21:53:50 +00:00
gboolean repaint_scheduled = FALSE;
cairo_rectangle_int_t clip;
if (meta_shaped_texture_update_area (priv->texture, x, y, width, height, &clip))
{
cairo_region_t *unobscured_region;
surface-actor: Move unobscured_region processing here https://bugzilla.gnome.org/show_bug.cgi?id=720631
2013-12-06 16:57:40 +00:00
shaped-texture: Move MetaCullable helpers to MetaSurfaceActor Now that MetaShapedTexture is not a ClutterActor anymore, it does not make sense to make it a MetaCullable semi-implementation. This is, naturally, a responsibility of MetaSurfaceActor, since now MetaShapedTexture is a ClutterContent and as such, it only cares about what to draw. Move the MetaCullable implementation of MetaShapedTexture to MetaSurfaceActor. https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
2019-01-29 21:53:50 +00:00
unobscured_region = effective_unobscured_region (self);
if (unobscured_region)
{
cairo_region_t *intersection;
if (cairo_region_is_empty (unobscured_region))
return;
intersection = cairo_region_copy (unobscured_region);
cairo_region_intersect_rectangle (intersection, &clip);
if (!cairo_region_is_empty (intersection))
{
surface-actor: Queue rectangles of update region separately This aims to help reduce the amount of pixels redrawn on the screen in case the damage rectangle is partially occluded by another surface. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2965>
2023-04-17 11:27:18 +00:00
int i, n_rectangles;
n_rectangles = cairo_region_num_rectangles (intersection);
for (i = 0; i < n_rectangles; i++)
{
cairo_rectangle_int_t rect;
cairo_region_get_rectangle (intersection, i, &rect);
clutter_actor_queue_redraw_with_clip (CLUTTER_ACTOR (self), &rect);
}
shaped-texture: Move MetaCullable helpers to MetaSurfaceActor Now that MetaShapedTexture is not a ClutterActor anymore, it does not make sense to make it a MetaCullable semi-implementation. This is, naturally, a responsibility of MetaSurfaceActor, since now MetaShapedTexture is a ClutterContent and as such, it only cares about what to draw. Move the MetaCullable implementation of MetaShapedTexture to MetaSurfaceActor. https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
2019-01-29 21:53:50 +00:00
repaint_scheduled = TRUE;
}
cairo_region_destroy (intersection);
}
else
{
clutter_actor_queue_redraw_with_clip (CLUTTER_ACTOR (self), &clip);
repaint_scheduled = TRUE;
}
}
if (repaint_scheduled)
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
g_signal_emit (self, signals[REPAINT_SCHEDULED], 0);
surface-actor: Move unobscured_region processing here https://bugzilla.gnome.org/show_bug.cgi?id=720631
2013-12-06 16:57:40 +00:00
}
Introduce MetaSurfaceActor for drawing MetaWindowActor content Instead of having MetaWindowActor only have one single MetaShapedTexture as actor drawing its content, introduce a new abstract MetaSurfaceActor that takes care of drawing. This is one step in the direction to decouple MetaWaylandSurface with a MetaWindow and MetaWindowActor (except for shell/xdg surfaces) in order to finally support subsurfaces like features, or any feature where window is not drawn using a single texture. The first step, implemented in this patch, is to not have MetaWindowActor work directly with a shaped texture. There are still some cases where it simply gets the texture and goes on as before, but this should be changed by either removing the need of going via MetaWindowActor or by adding some generic interface to MetaSurfaceActor that doesn't limit its functionality to one shaped texture. There should be no visible difference nor after this patch, but meta_window_actor_get_texture() and meta_surface_actor_get_texture() should be deprecated when equivalent functionality has been introduced. Signed-off-by: Jonas Ådahl <jadahl@gmail.com> https://bugzilla.gnome.org/show_bug.cgi?id=705502
2013-10-13 11:47:53 +00:00
gboolean
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
meta_surface_actor_is_obscured (MetaSurfaceActor *self)
Introduce MetaSurfaceActor for drawing MetaWindowActor content Instead of having MetaWindowActor only have one single MetaShapedTexture as actor drawing its content, introduce a new abstract MetaSurfaceActor that takes care of drawing. This is one step in the direction to decouple MetaWaylandSurface with a MetaWindow and MetaWindowActor (except for shell/xdg surfaces) in order to finally support subsurfaces like features, or any feature where window is not drawn using a single texture. The first step, implemented in this patch, is to not have MetaWindowActor work directly with a shaped texture. There are still some cases where it simply gets the texture and goes on as before, but this should be changed by either removing the need of going via MetaWindowActor or by adding some generic interface to MetaSurfaceActor that doesn't limit its functionality to one shaped texture. There should be no visible difference nor after this patch, but meta_window_actor_get_texture() and meta_surface_actor_get_texture() should be deprecated when equivalent functionality has been introduced. Signed-off-by: Jonas Ådahl <jadahl@gmail.com> https://bugzilla.gnome.org/show_bug.cgi?id=705502
2013-10-13 11:47:53 +00:00
{
shaped-texture: Move MetaCullable helpers to MetaSurfaceActor Now that MetaShapedTexture is not a ClutterActor anymore, it does not make sense to make it a MetaCullable semi-implementation. This is, naturally, a responsibility of MetaSurfaceActor, since now MetaShapedTexture is a ClutterContent and as such, it only cares about what to draw. Move the MetaCullable implementation of MetaShapedTexture to MetaSurfaceActor. https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
2019-01-29 21:53:50 +00:00
cairo_region_t *unobscured_region;
Use G_DECLARE_DERIVABLE/FINAL_TYPE on some types This is only for types in the `Meta` namespace. * Clears up a lot of boilerplate * We get `g_autoptr` support for free
2018-10-31 10:47:17 +00:00
shaped-texture: Move MetaCullable helpers to MetaSurfaceActor Now that MetaShapedTexture is not a ClutterActor anymore, it does not make sense to make it a MetaCullable semi-implementation. This is, naturally, a responsibility of MetaSurfaceActor, since now MetaShapedTexture is a ClutterContent and as such, it only cares about what to draw. Move the MetaCullable implementation of MetaShapedTexture to MetaSurfaceActor. https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
2019-01-29 21:53:50 +00:00
unobscured_region = effective_unobscured_region (self);
if (unobscured_region)
return cairo_region_is_empty (unobscured_region);
else
return FALSE;
surface-actor: Move unobscured_region processing here https://bugzilla.gnome.org/show_bug.cgi?id=720631
2013-12-06 16:57:40 +00:00
}
surface-actor: Add API to check obscuredness per stage view Our main use case of `is_obscured()` is frame callback emission. Since we now support stage views running at differt speeds, we need to know whether an actor is visible on a specific stage view in order to schedule frame callbacks accordingly. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1468>
2020-10-05 11:18:15 +00:00
gboolean
meta_surface_actor_is_obscured_on_stage_view (MetaSurfaceActor *self,
ClutterStageView *stage_view,
float *unobscurred_fraction)
{
cairo_region_t *unobscured_region;
unobscured_region = effective_unobscured_region (self);
if (unobscured_region)
{
MetaSurfaceActorPrivate *priv =
meta_surface_actor_get_instance_private (self);
cairo_region_t *intersection_region;
cairo_rectangle_int_t stage_rect;
float x, y;
float bounds_width, bounds_height;
float bounds_size;
int intersection_size = 0;
int n_rects, i;
if (cairo_region_is_empty (unobscured_region))
return TRUE;
intersection_region = cairo_region_copy (unobscured_region);
clutter_actor_get_transformed_position (CLUTTER_ACTOR (self), &x, &y);
cairo_region_translate (intersection_region, x, y);
clutter_stage_view_get_layout (stage_view, &stage_rect);
cairo_region_intersect_rectangle (intersection_region,
&stage_rect);
if (cairo_region_is_empty (intersection_region))
{
cairo_region_destroy (intersection_region);
return TRUE;
}
else if (!unobscurred_fraction)
{
cairo_region_destroy (intersection_region);
return FALSE;
}
clutter_content_get_preferred_size (CLUTTER_CONTENT (priv->texture),
&bounds_width,
&bounds_height);
bounds_size = bounds_width * bounds_height;
n_rects = cairo_region_num_rectangles (intersection_region);
for (i = 0; i < n_rects; i++)
{
cairo_rectangle_int_t rect;
cairo_region_get_rectangle (intersection_region, i, &rect);
surface-actor: Fix unobscurred_fraction calculation This calculation wrongly applied a `x2 - x1` pattern. Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/1971 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2169>
2021-12-19 22:42:57 +00:00
intersection_size += rect.width * rect.height;
surface-actor: Add API to check obscuredness per stage view Our main use case of `is_obscured()` is frame callback emission. Since we now support stage views running at differt speeds, we need to know whether an actor is visible on a specific stage view in order to schedule frame callbacks accordingly. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1468>
2020-10-05 11:18:15 +00:00
}
cairo_region_destroy (intersection_region);
g_return_val_if_fail (bounds_size > 0, FALSE);
*unobscurred_fraction = CLAMP (intersection_size / bounds_size, 0, 1);
return FALSE;
}
return !clutter_actor_is_effectively_on_stage_view (CLUTTER_ACTOR (self),
stage_view);
}
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
void
meta_surface_actor_set_input_region (MetaSurfaceActor *self,
cairo_region_t *region)
surface-actor: Move unobscured_region processing here https://bugzilla.gnome.org/show_bug.cgi?id=720631
2013-12-06 16:57:40 +00:00
{
Use G_DECLARE_DERIVABLE/FINAL_TYPE on some types This is only for types in the `Meta` namespace. * Clears up a lot of boilerplate * We get `g_autoptr` support for free
2018-10-31 10:47:17 +00:00
MetaSurfaceActorPrivate *priv =
meta_surface_actor_get_instance_private (self);
surface-actor: Move unobscured_region processing here https://bugzilla.gnome.org/show_bug.cgi?id=720631
2013-12-06 16:57:40 +00:00
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
if (priv->input_region)
cairo_region_destroy (priv->input_region);
if (region)
priv->input_region = cairo_region_reference (region);
else
priv->input_region = NULL;
shaped-texture: Move unobscured_region processing here We want to remove a bunch of auxilliary duties from the MetaWindowActor and MetaSurfaceActor, including some details of how culling is done. Move the unobscured region culling code to the MetaShapedTexture, which helps the actor become "more independent". https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-05 19:06:32 +00:00
}
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
void
meta_surface_actor_set_opaque_region (MetaSurfaceActor *self,
cairo_region_t *region)
shaped-texture: Move unobscured_region processing here We want to remove a bunch of auxilliary duties from the MetaWindowActor and MetaSurfaceActor, including some details of how culling is done. Move the unobscured region culling code to the MetaShapedTexture, which helps the actor become "more independent". https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-05 19:06:32 +00:00
{
Use G_DECLARE_DERIVABLE/FINAL_TYPE on some types This is only for types in the `Meta` namespace. * Clears up a lot of boilerplate * We get `g_autoptr` support for free
2018-10-31 10:47:17 +00:00
MetaSurfaceActorPrivate *priv =
meta_surface_actor_get_instance_private (self);
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
meta_shaped_texture_set_opaque_region (priv->texture, region);
Introduce MetaSurfaceActor for drawing MetaWindowActor content Instead of having MetaWindowActor only have one single MetaShapedTexture as actor drawing its content, introduce a new abstract MetaSurfaceActor that takes care of drawing. This is one step in the direction to decouple MetaWaylandSurface with a MetaWindow and MetaWindowActor (except for shell/xdg surfaces) in order to finally support subsurfaces like features, or any feature where window is not drawn using a single texture. The first step, implemented in this patch, is to not have MetaWindowActor work directly with a shaped texture. There are still some cases where it simply gets the texture and goes on as before, but this should be changed by either removing the need of going via MetaWindowActor or by adding some generic interface to MetaSurfaceActor that doesn't limit its functionality to one shaped texture. There should be no visible difference nor after this patch, but meta_window_actor_get_texture() and meta_surface_actor_get_texture() should be deprecated when equivalent functionality has been introduced. Signed-off-by: Jonas Ådahl <jadahl@gmail.com> https://bugzilla.gnome.org/show_bug.cgi?id=705502
2013-10-13 11:47:53 +00:00
}
surface-actor-x11: Unredirect ARGB32 windows with full opaque regions We can detect that these windows are already fully opaque, so allow them to unredirect. Allows unredirecting Totem during video playback, giving a significant speed boost.
2016-03-21 20:43:50 +00:00
cairo_region_t *
Use G_DECLARE_DERIVABLE/FINAL_TYPE on some types This is only for types in the `Meta` namespace. * Clears up a lot of boilerplate * We get `g_autoptr` support for free
2018-10-31 10:47:17 +00:00
meta_surface_actor_get_opaque_region (MetaSurfaceActor *self)
surface-actor-x11: Unredirect ARGB32 windows with full opaque regions We can detect that these windows are already fully opaque, so allow them to unredirect. Allows unredirecting Totem during video playback, giving a significant speed boost.
2016-03-21 20:43:50 +00:00
{
Use G_DECLARE_DERIVABLE/FINAL_TYPE on some types This is only for types in the `Meta` namespace. * Clears up a lot of boilerplate * We get `g_autoptr` support for free
2018-10-31 10:47:17 +00:00
MetaSurfaceActorPrivate *priv =
meta_surface_actor_get_instance_private (self);
surface-actor-x11: Unredirect ARGB32 windows with full opaque regions We can detect that these windows are already fully opaque, so allow them to unredirect. Allows unredirecting Totem during video playback, giving a significant speed boost.
2016-03-21 20:43:50 +00:00
return meta_shaped_texture_get_opaque_region (priv->texture);
}
surface-actor: Add setters for set_input_region / set_opaque_region Subsurfaces won't have a MetaWindow or MetaWindowActor to fetch these from, so they need to be tied directly to the MetaSurfaceActor.
2013-11-21 22:45:05 +00:00
void
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
meta_surface_actor_process_damage (MetaSurfaceActor *self,
int x, int y, int width, int height)
surface content
2013-12-09 21:01:07 +00:00
{
Use G_DECLARE_DERIVABLE/FINAL_TYPE on some types This is only for types in the `Meta` namespace. * Clears up a lot of boilerplate * We get `g_autoptr` support for free
2018-10-31 10:47:17 +00:00
MetaSurfaceActorPrivate *priv =
meta_surface_actor_get_instance_private (self);
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
surface-actor: Add `meta_surface_actor_is_frozen()` Change the internal `is_frozen()` API to be available publicly. https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
2019-12-06 15:35:37 +00:00
if (meta_surface_actor_is_frozen (self))
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
{
/* The window is frozen due to an effect in progress: we ignore damage
* here on the off chance that this will stop the corresponding
* texture_from_pixmap from being update.
*
surface-actor: Keep track of ignored damage We ignore all damage while a surface is frozen and queue a full update instead once it's thawed. While not super efficient, this isn't overly bad for the intended case of catching up with any updates that happened during a compositor effect. However when extended frame sync is used, surfaces are also frozen while the client is drawing a frame, in which case the current behavior is pretty damaging (pun intended), as we end up redrawing the entire window each frame. To address this, keep track of the actual damage we ignore and apply it when the surface is thawed. https://bugzilla.gnome.org/show_bug.cgi?id=767798
2016-06-17 15:45:20 +00:00
* pending_damage tracks any damage that happened while the window was
* frozen so that when can apply it when the window becomes unfrozen.
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
*
* It should be noted that this is an unreliable mechanism since it's
* quite likely that drivers will aim to provide a zero-copy
* implementation of the texture_from_pixmap extension and in those cases
* any drawing done to the window is always immediately reflected in the
* texture regardless of damage event handling.
*/
surface-actor: Keep track of ignored damage We ignore all damage while a surface is frozen and queue a full update instead once it's thawed. While not super efficient, this isn't overly bad for the intended case of catching up with any updates that happened during a compositor effect. However when extended frame sync is used, surfaces are also frozen while the client is drawing a frame, in which case the current behavior is pretty damaging (pun intended), as we end up redrawing the entire window each frame. To address this, keep track of the actual damage we ignore and apply it when the surface is thawed. https://bugzilla.gnome.org/show_bug.cgi?id=767798
2016-06-17 15:45:20 +00:00
cairo_rectangle_int_t rect = { .x = x, .y = y, .width = width, .height = height };
if (!priv->pending_damage)
priv->pending_damage = cairo_region_create_rectangle (&rect);
else
cairo_region_union_rectangle (priv->pending_damage, &rect);
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
return;
}
META_SURFACE_ACTOR_GET_CLASS (self)->process_damage (self, x, y, width, height);
surface content
2013-12-09 21:01:07 +00:00
}
void
MetaSurfaceActor: move freeze accounting to MetaWindowActor Turns out we only ever need to freeze/thaw whole windows, not surfaces or subsurfaces. This will allow removing the surface actor without losing the count.
2014-02-24 21:00:12 +00:00
meta_surface_actor_set_frozen (MetaSurfaceActor *self,
gboolean frozen)
surface content
2013-12-09 21:01:07 +00:00
{
Use G_DECLARE_DERIVABLE/FINAL_TYPE on some types This is only for types in the `Meta` namespace. * Clears up a lot of boilerplate * We get `g_autoptr` support for free
2018-10-31 10:47:17 +00:00
MetaSurfaceActorPrivate *priv =
meta_surface_actor_get_instance_private (self);
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
window-actor: Freeze subsurfaces as well In order to prevent glitches in animations, make sure we freeze all surfaces of a window actor. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1339
2020-06-29 13:15:46 +00:00
if (priv->frozen == frozen)
return;
MetaSurfaceActor: move freeze accounting to MetaWindowActor Turns out we only ever need to freeze/thaw whole windows, not surfaces or subsurfaces. This will allow removing the surface actor without losing the count.
2014-02-24 21:00:12 +00:00
priv->frozen = frozen;
surface-actor: Move work out of _new constructor If we want to have any chance at creating subclasses of MetaSurfaceActor, we can't do work in the constructor...
2013-12-06 19:19:32 +00:00
surface-actor: Keep track of ignored damage We ignore all damage while a surface is frozen and queue a full update instead once it's thawed. While not super efficient, this isn't overly bad for the intended case of catching up with any updates that happened during a compositor effect. However when extended frame sync is used, surfaces are also frozen while the client is drawing a frame, in which case the current behavior is pretty damaging (pun intended), as we end up redrawing the entire window each frame. To address this, keep track of the actual damage we ignore and apply it when the surface is thawed. https://bugzilla.gnome.org/show_bug.cgi?id=767798
2016-06-17 15:45:20 +00:00
if (!frozen && priv->pending_damage)
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
{
surface-actor: Keep track of ignored damage We ignore all damage while a surface is frozen and queue a full update instead once it's thawed. While not super efficient, this isn't overly bad for the intended case of catching up with any updates that happened during a compositor effect. However when extended frame sync is used, surfaces are also frozen while the client is drawing a frame, in which case the current behavior is pretty damaging (pun intended), as we end up redrawing the entire window each frame. To address this, keep track of the actual damage we ignore and apply it when the surface is thawed. https://bugzilla.gnome.org/show_bug.cgi?id=767798
2016-06-17 15:45:20 +00:00
int i, n_rects = cairo_region_num_rectangles (priv->pending_damage);
cairo_rectangle_int_t rect;
MetaSurfaceActor: move freeze accounting to MetaWindowActor Turns out we only ever need to freeze/thaw whole windows, not surfaces or subsurfaces. This will allow removing the surface actor without losing the count.
2014-02-24 21:00:12 +00:00
/* Since we ignore damage events while a window is frozen for certain effects
surface-actor: Keep track of ignored damage We ignore all damage while a surface is frozen and queue a full update instead once it's thawed. While not super efficient, this isn't overly bad for the intended case of catching up with any updates that happened during a compositor effect. However when extended frame sync is used, surfaces are also frozen while the client is drawing a frame, in which case the current behavior is pretty damaging (pun intended), as we end up redrawing the entire window each frame. To address this, keep track of the actual damage we ignore and apply it when the surface is thawed. https://bugzilla.gnome.org/show_bug.cgi?id=767798
2016-06-17 15:45:20 +00:00
* we need to apply the tracked damage now. */
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
surface-actor: Keep track of ignored damage We ignore all damage while a surface is frozen and queue a full update instead once it's thawed. While not super efficient, this isn't overly bad for the intended case of catching up with any updates that happened during a compositor effect. However when extended frame sync is used, surfaces are also frozen while the client is drawing a frame, in which case the current behavior is pretty damaging (pun intended), as we end up redrawing the entire window each frame. To address this, keep track of the actual damage we ignore and apply it when the surface is thawed. https://bugzilla.gnome.org/show_bug.cgi?id=767798
2016-06-17 15:45:20 +00:00
for (i = 0; i < n_rects; i++)
{
cairo_region_get_rectangle (priv->pending_damage, i, &rect);
meta_surface_actor_process_damage (self, rect.x, rect.y,
rect.width, rect.height);
}
g_clear_pointer (&priv->pending_damage, cairo_region_destroy);
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
}
}
surface-actor: Add `meta_surface_actor_is_frozen()` Change the internal `is_frozen()` API to be available publicly. https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
2019-12-06 15:35:37 +00:00
gboolean
meta_surface_actor_is_frozen (MetaSurfaceActor *self)
{
MetaSurfaceActorPrivate *priv =
meta_surface_actor_get_instance_private (self);
return priv->frozen;
}
Copy permalink