isa/mutter
1
0
Fork 0
mirror of https://github.com/brl/mutter.git synced 2024-11-24 09:00:42 -05:00
Code Issues Packages Projects Releases Wiki Activity
7759adf8e9
mutter/src/compositor/meta-surface-actor.c

397 lines
12 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; -*- */
/**
* SECTION:meta-surface-actor
* @title: MetaSurfaceActor
* @short_description: An actor representing a surface in the scene graph
*
* A surface can be either a shaped texture, or a group of shaped texture,
* used to draw the content of a window.
*/
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"
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
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 "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 17:21:11 -05: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 04:36:24 -04:00
#include "clutter/clutter.h"
#include "compositor/meta-cullable.h"
#include "compositor/meta-shaped-texture-private.h"
#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 07:47:53 -04:00
struct _MetaSurfaceActorPrivate
{
Revert "ff" This reverts commit 74462133ca7e85aabaac634517dbd5dd0a7742c2. Pushed by accident, if it wasn't obvious...
2013-11-19 11:22:49 -05: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-18 21:27:20 -05: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 17:21:11 -05: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 11:45:20 -04: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 16:00:12 -05:00
guint frozen : 1;
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: Make Cullable Make MetaWindowActor chain up to the generic default MetaCullable implementation, and remove the helper methods for MetaSurfaceActor and MetaShapedTexture.
2013-11-21 16:25:20 -05: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 17:21:11 -05: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 07:40:39 -04: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 17:21:11 -05:00
G_IMPLEMENT_INTERFACE (META_TYPE_CULLABLE, cullable_iface_init));
enum {
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 05:05:34 -04: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 17:21:11 -05: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 11:57:40 -05: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-18 21:27:20 -05:00
static void
meta_surface_actor_pick (ClutterActor *actor,
const ClutterColor *color)
{
MetaSurfaceActor *self = META_SURFACE_ACTOR (actor);
MetaSurfaceActorPrivate *priv = self->priv;
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 07:32:08 -05: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-18 21:27:20 -05:00
if (!clutter_actor_should_pick_paint (actor))
return;
/* If there is no region then use the regular pick */
if (priv->input_region == NULL)
CLUTTER_ACTOR_CLASS (meta_surface_actor_parent_class)->pick (actor, color);
else
{
int n_rects;
float *rectangles;
int i;
CoglPipeline *pipeline;
CoglContext *ctx;
CoglFramebuffer *fb;
CoglColor cogl_color;
n_rects = cairo_region_num_rectangles (priv->input_region);
rectangles = g_alloca (sizeof (float) * 4 * n_rects);
for (i = 0; i < n_rects; i++)
{
cairo_rectangle_int_t rect;
int pos = i * 4;
cairo_region_get_rectangle (priv->input_region, i, &rect);
rectangles[pos + 0] = rect.x;
rectangles[pos + 1] = rect.y;
rectangles[pos + 2] = rect.x + rect.width;
rectangles[pos + 3] = rect.y + rect.height;
}
ctx = clutter_backend_get_cogl_context (clutter_get_default_backend ());
fb = cogl_get_draw_framebuffer ();
cogl_color_init_from_4ub (&cogl_color, color->red, color->green, color->blue, color->alpha);
pipeline = cogl_pipeline_new (ctx);
cogl_pipeline_set_color (pipeline, &cogl_color);
cogl_framebuffer_draw_rectangles (fb, pipeline, rectangles, n_rects);
cogl_object_unref (pipeline);
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 07:32:08 -05: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 12:44:55 -04: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 07:32:08 -05: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 12:44:55 -04: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 07:32:08 -05:00
while (clutter_actor_iter_next (&iter, &child))
clutter_actor_paint (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-18 21:27:20 -05: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 12:14:34 -04: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-18 21:27:20 -05:00
static void
meta_surface_actor_dispose (GObject *object)
{
MetaSurfaceActor *self = META_SURFACE_ACTOR (object);
MetaSurfaceActorPrivate *priv = self->priv;
g_clear_pointer (&priv->input_region, cairo_region_destroy);
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 07:47:53 -04: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-18 21:27:20 -05: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 12:14:34 -04: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-18 21:27:20 -05: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
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 05:05:34 -04: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 07:47:53 -04: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 16:25:20 -05:00
static void
meta_surface_actor_cull_out (MetaCullable *cullable,
surface-actor: Reindent
2013-12-06 20:28:39 -05: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 16:25:20 -05:00
{
meta_cullable_cull_out_children (cullable, unobscured_region, clip_region);
}
static void
meta_surface_actor_reset_culling (MetaCullable *cullable)
{
meta_cullable_reset_culling_children (cullable);
}
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 05:05:34 -04: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 07:47:53 -04:00
static void
meta_surface_actor_init (MetaSurfaceActor *self)
{
MetaSurfaceActorPrivate *priv;
priv = self->priv = G_TYPE_INSTANCE_GET_PRIVATE (self,
META_TYPE_SURFACE_ACTOR,
MetaSurfaceActorPrivate);
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 14:19:32 -05:00
priv->texture = META_SHAPED_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 05:05:34 -04:00
g_signal_connect_object (priv->texture, "size-changed",
G_CALLBACK (texture_size_changed), self, 0);
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 14:19:32 -05:00
clutter_actor_add_child (CLUTTER_ACTOR (self), CLUTTER_ACTOR (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 07:47:53 -04:00
}
cairo_surface_t *
meta_surface_actor_get_image (MetaSurfaceActor *self,
cairo_rectangle_int_t *clip)
{
return meta_shaped_texture_get_image (self->priv->texture, clip);
}
MetaShapedTexture *
meta_surface_actor_get_texture (MetaSurfaceActor *self)
{
return self->priv->texture;
}
wayland: Update the CoglTexture in the MetaWaylandSurface It doesn't make sense to update it in the surface actor. It's also theoretically wrong to update the buffer's texture on surface commit, too, because it's buffer state, not surface state, but I don't think there's any place we use a wl_buffer without a wl_surface.
2014-08-21 16:19:23 -04:00
static 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 17:21:11 -05:00
meta_surface_actor_update_area (MetaSurfaceActor *self,
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 11:57:40 -05:00
{
MetaSurfaceActorPrivate *priv = self->priv;
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
if (meta_shaped_texture_update_area (priv->texture, x, y, width, height))
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 11:57:40 -05: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 07:47:53 -04: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 17:21:11 -05: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 07:47:53 -04:00
{
MetaSurfaceActorPrivate *priv = self->priv;
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
return meta_shaped_texture_is_obscured (priv->texture);
surface-actor: Move unobscured_region processing here https://bugzilla.gnome.org/show_bug.cgi?id=720631
2013-12-06 11:57:40 -05: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_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 11:57:40 -05:00
{
MetaSurfaceActorPrivate *priv = self->priv;
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
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 14:06:32 -05: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_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 14:06:32 -05:00
{
MetaSurfaceActorPrivate *priv = self->priv;
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
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 07:47:53 -04: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 16:43:50 -04:00
cairo_region_t *
meta_surface_actor_get_opaque_region (MetaSurfaceActor *actor)
{
MetaSurfaceActorPrivate *priv = actor->priv;
return meta_shaped_texture_get_opaque_region (priv->texture);
}
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
static gboolean
is_frozen (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
{
surface-actor: Don't use self->priv->foo directly I don't like it...
2013-12-06 12:00:13 -05:00
MetaSurfaceActorPrivate *priv = self->priv;
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
return priv->frozen;
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
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
meta_surface_actor_process_damage (MetaSurfaceActor *self,
int x, int y, int width, int height)
surface content
2013-12-09 16:01:07 -05:00
{
Revert unintentional merge from wip/surface-content to wayland This reverts a lot of commits.
2014-01-22 09:16:56 -05:00
MetaSurfaceActorPrivate *priv = self->priv;
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
if (is_frozen (self))
{
/* 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 11:45:20 -04: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 17:21:11 -05: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 11:45:20 -04: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 17:21:11 -05:00
return;
}
META_SURFACE_ACTOR_GET_CLASS (self)->process_damage (self, x, y, width, height);
surface-actor: Call process_damage even when the actor is invisible Otherwise, surface-actor-x11 won't be marked as having received damage, which is vital to updating the actual surface.
2014-08-21 18:30:56 -04:00
if (meta_surface_actor_is_visible (self))
meta_surface_actor_update_area (self, x, y, width, height);
surface content
2013-12-09 16:01:07 -05: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 17:21:11 -05:00
meta_surface_actor_pre_paint (MetaSurfaceActor *self)
surface content
2013-12-09 16:01:07 -05: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
META_SURFACE_ACTOR_GET_CLASS (self)->pre_paint (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-18 21:27:20 -05: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
gboolean
meta_surface_actor_is_argb32 (MetaSurfaceActor *self)
{
surface-actor: Implement is_argb32 generically for both X11 and Wayland cogl_texture_get_components can be used on both X11 and Wayland backends. Technically, the detection is different: we actually check the actual RENDER format in the old code, while Cogl simply assumes that any pixmap with a depth >= 32 is ARGB32. Since Cogl already seems to be working with its internal checks, it makes more sense to use Cogl's check rather than keeping our own.
2014-03-25 17:02:50 -04:00
MetaShapedTexture *stex = meta_surface_actor_get_texture (self);
CoglTexture *texture = meta_shaped_texture_get_texture (stex);
/* If we don't have a texture, like during initialization, assume
meta-surface-actor: Fix is_argb32 for unredirected windows meta_surface_actor_is_argb32 assumes that lack of stex means that a window is ARGB32. When we unredirect a window we detach the texture so we end up without a texture. Given that should_unredirect returns FALSE when a window is argb32, we know that this window is indeed not ARGB32. Returing TRUE in that case causes us to flip between redirected and unredirected on every paint. So fix that by returning FALSE in that case.
2014-08-26 12:22:33 -04:00
* that we're ARGB32.
*
* If we are unredirected and we have no texture assume that we are
* not ARGB32 otherwise we wouldn't be unredirected in the first
* place. This prevents us from continually redirecting and
* unredirecting on every paint.
*/
surface-actor: Implement is_argb32 generically for both X11 and Wayland cogl_texture_get_components can be used on both X11 and Wayland backends. Technically, the detection is different: we actually check the actual RENDER format in the old code, while Cogl simply assumes that any pixmap with a depth >= 32 is ARGB32. Since Cogl already seems to be working with its internal checks, it makes more sense to use Cogl's check rather than keeping our own.
2014-03-25 17:02:50 -04:00
if (!texture)
meta-surface-actor: Fix is_argb32 for unredirected windows meta_surface_actor_is_argb32 assumes that lack of stex means that a window is ARGB32. When we unredirect a window we detach the texture so we end up without a texture. Given that should_unredirect returns FALSE when a window is argb32, we know that this window is indeed not ARGB32. Returing TRUE in that case causes us to flip between redirected and unredirected on every paint. So fix that by returning FALSE in that case.
2014-08-26 12:22:33 -04:00
return !meta_surface_actor_is_unredirected (self);
surface-actor: Implement is_argb32 generically for both X11 and Wayland cogl_texture_get_components can be used on both X11 and Wayland backends. Technically, the detection is different: we actually check the actual RENDER format in the old code, while Cogl simply assumes that any pixmap with a depth >= 32 is ARGB32. Since Cogl already seems to be working with its internal checks, it makes more sense to use Cogl's check rather than keeping our own.
2014-03-25 17:02:50 -04:00
switch (cogl_texture_get_components (texture))
{
case COGL_TEXTURE_COMPONENTS_A:
case COGL_TEXTURE_COMPONENTS_RGBA:
return TRUE;
case COGL_TEXTURE_COMPONENTS_RG:
case COGL_TEXTURE_COMPONENTS_RGB:
case COGL_TEXTURE_COMPONENTS_DEPTH:
return FALSE;
default:
g_assert_not_reached ();
}
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
}
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-18 21:27:20 -05: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
gboolean
meta_surface_actor_is_visible (MetaSurfaceActor *self)
{
return META_SURFACE_ACTOR_GET_CLASS (self)->is_visible (self);
surface content
2013-12-09 16:01:07 -05: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 16:00:12 -05:00
meta_surface_actor_set_frozen (MetaSurfaceActor *self,
gboolean frozen)
surface content
2013-12-09 16:01:07 -05:00
{
Revert unintentional merge from wip/surface-content to wayland This reverts a lot of commits.
2014-01-22 09:16:56 -05:00
MetaSurfaceActorPrivate *priv = self->priv;
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
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
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 14:19:32 -05: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 11:45:20 -04: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 17:21:11 -05: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 11:45:20 -04: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 16:00:12 -05: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 11:45:20 -04: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 17:21:11 -05: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 11:45:20 -04: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 17:21:11 -05:00
}
}
gboolean
meta_surface_actor_should_unredirect (MetaSurfaceActor *self)
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 14:19:32 -05: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
return META_SURFACE_ACTOR_GET_CLASS (self)->should_unredirect (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-18 21:27:20 -05: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_set_unredirected (MetaSurfaceActor *self,
gboolean unredirected)
{
META_SURFACE_ACTOR_GET_CLASS (self)->set_unredirected (self, unredirected);
}
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-18 21:27:20 -05: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
gboolean
meta_surface_actor_is_unredirected (MetaSurfaceActor *self)
{
return META_SURFACE_ACTOR_GET_CLASS (self)->is_unredirected (self);
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 14:19:32 -05:00
}
MetaSurfaceActor: add a generic hook to retrieve the MetaWindow This way we can find the window for a ClutterEvent even when running as an x11 compositor.
2014-02-26 20:21:51 -05:00
MetaWindow *
meta_surface_actor_get_window (MetaSurfaceActor *self)
{
return META_SURFACE_ACTOR_GET_CLASS (self)->get_window (self);
}
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
void
meta_surface_actor_set_transform (MetaSurfaceActor *self,
MetaMonitorTransform transform)
{
MetaSurfaceActorPrivate *priv = self->priv;
meta_shaped_texture_set_transform (priv->texture, transform);
}
Reference in New Issue Copy Permalink