isa/mutter
1
0
Fork 0
mirror of https://github.com/brl/mutter.git synced 2024-12-04 05:40:41 -05:00
Code Issues Packages Projects Releases Wiki Activity
ad0e19a034
mutter/src/compositor/meta-surface-actor.h

60 lines
2.3 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 07:47:53 -04:00
/* -*- mode: C; c-file-style: "gnu"; indent-tabs-mode: nil; -*- */
#ifndef META_SURFACE_ACTOR_PRIVATE_H
#define META_SURFACE_ACTOR_PRIVATE_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 04:36:24 -04:00
#include "config.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 07:47:53 -04:00
shaped-texture: Add support for texture transform This adds the necessary bits to support Wayland buffer transforms. The main part here is to properly setup the Cogl pipeline and to recalculate the size of the painted area accordingly, so culling etc. still works. The choosen approach additionally lays groundwork for Wayland wp_viewporter support. https://gitlab.gnome.org/GNOME/mutter/merge_requests/322
2018-11-24 12:27:29 -05:00
#include "backends/meta-backend-types.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 04:36:24 -04:00
#include "meta/meta-shaped-texture.h"
#include "meta/window.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 07:47:53 -04:00
G_BEGIN_DECLS
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 06:47:17 -04:00
#define META_TYPE_SURFACE_ACTOR (meta_surface_actor_get_type ())
G_DECLARE_DERIVABLE_TYPE (MetaSurfaceActor,
meta_surface_actor,
META, SURFACE_ACTOR,
ClutterActor)
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 07:47:53 -04:00
struct _MetaSurfaceActorClass
{
/*< private >*/
ClutterActorClass parent_class;
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 17:21:11 -05:00
void (* process_damage) (MetaSurfaceActor *actor,
int x, int y, int width, int height);
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 04:00:46 -04:00
gboolean (* is_opaque) (MetaSurfaceActor *actor);
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 07:47:53 -04:00
};
MetaShapedTexture *meta_surface_actor_get_texture (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 17:21:26 -04:00
void meta_surface_actor_update_area (MetaSurfaceActor *self,
int x,
int y,
int width,
int height);
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 14:06:32 -05:00
gboolean meta_surface_actor_is_obscured (MetaSurfaceActor *self);
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 07:18:15 -04:00
gboolean meta_surface_actor_is_obscured_on_stage_view (MetaSurfaceActor *self,
ClutterStageView *stage_view,
float *unobscurred_fraction);
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 07:47:53 -04:00
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 17:45:05 -05:00
void meta_surface_actor_set_input_region (MetaSurfaceActor *self,
cairo_region_t *region);
void meta_surface_actor_set_opaque_region (MetaSurfaceActor *self,
cairo_region_t *region);
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 16:43:50 -04:00
cairo_region_t * meta_surface_actor_get_opaque_region (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 07:47:53 -04: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 17:21:11 -05:00
void meta_surface_actor_process_damage (MetaSurfaceActor *actor,
int x, int y, int width, int height);
surface-actor: Remove 'pre-paint' vfunc The vfunc was not tied to "paint", but was used by MetaWindowActorX11 as part of the "update" mechanisms. In order to make that more clear, special case it in MetaWindowActorX11 by type checking the surface actor, handling the case without MetaSurfacActor abstraction. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
2020-05-29 13:18:47 -04: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 04:00:46 -04:00
gboolean meta_surface_actor_is_opaque (MetaSurfaceActor *actor);
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 17:21:11 -05: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 10:35:37 -05:00
gboolean meta_surface_actor_is_frozen (MetaSurfaceActor *actor);
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 16:00:12 -05:00
void meta_surface_actor_set_frozen (MetaSurfaceActor *actor,
gboolean frozen);
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 07:47:53 -04:00
G_END_DECLS
#endif /* META_SURFACE_ACTOR_PRIVATE_H */
Reference in New Issue Copy Permalink