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

323 lines
9.9 KiB
C
Raw Normal View History

window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
/* -*- mode: C; c-file-style: "gnu"; indent-tabs-mode: nil; -*- */
/*
* Copyright (C) 2013 Red Hat
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of the
* License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
*
* You should have received a copy of the GNU General Public License
Update license access method Dropped obsolete Free Software Foundation address pointing to the FSF website instead as suggested by https://www.gnu.org/licenses/gpl-howto.html keeping intact the important part of the historical notice as requested by the license. Resolving rpmlint reported issue E: incorrect-fsf-address. Signed-off-by: Sandro Bonazzola <sbonazzo@redhat.com> Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3155>
2023-08-07 09:50:23 +00:00
* along with this program; if not, see <http://www.gnu.org/licenses/>.
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
*
* Written by:
* Jasper St. Pierre <jstpierre@mecheye.net>
*/
#include "config.h"
Clean up include macros mess The order and way include macros were structured was chaotic, with no real common thread between files. Try to tidy up the mess with some common scheme, to make things look less messy.
2018-07-10 08:36:24 +00:00
#include "compositor/meta-surface-actor-wayland.h"
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
wayland: Send wl_surface.enter and wl_surface.leave Whenever a MetaSurfaceActor is painted, update the list of what outputs the surface is being drawed upon. Since we do this on paint, we effectively avoids this whenever the surface is not drawn, for example being minimized, on a non-active workspace, or simply outside of the damage region of a frame. DND icons and cursors are not affected by this patch, since they are not drawn as MetaSurfaceActors. If a MetaSurfaceActor or a parent is cloned, then we'll check the position of the original actor again when the clone is drawn, which is slightly expensive, but harmless. If the MetaShapedTexture instead is cloned, as GNOME Shell does in many cases, then these clones will not cause duplicate position checks. https://bugzilla.gnome.org/show_bug.cgi?id=744453
2015-02-03 07:49:52 +00:00
#include <math.h>
Don't include wayland/ by default either
2014-03-19 02:01:31 +00:00
Clean up include macros mess The order and way include macros were structured was chaotic, with no real common thread between files. Try to tidy up the mess with some common scheme, to make things look less messy.
2018-07-10 08:36:24 +00:00
#include "backends/meta-backend-private.h"
monitor-manager: Move logical monitor into its own file https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-13 02:37:11 +00:00
#include "backends/meta-logical-monitor.h"
surface-actor/wayland: Ensure screen-casted surfaces have a primary view Surfaces belonging to a screen-casted window should always be considered visible even if they are not visible on any stage view - be it because they are on a different workspace, minimized or occluded. Doing this in an optimal fashion is highly complex right now - interdependent with (and somewhat similar to) ClutterClones. Thus treat stream-casted surfaces similar to those with clones, with the small difference that even a fully invisible surface still gets a primary view - the fastest one. This ensures that clients never refresh too slow for a screen-cast, at the cost of sometimes refreshing too fast. The later only happens on certain multi-monitor setups and should thus be acceptable. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2789>
2023-02-11 06:03:43 +00:00
#include "backends/meta-screen-cast-window.h"
Clean up include macros mess The order and way include macros were structured was chaotic, with no real common thread between files. Try to tidy up the mess with some common scheme, to make things look less messy.
2018-07-10 08:36:24 +00:00
#include "compositor/meta-shaped-texture-private.h"
surface-actor/wayland: Ensure screen-casted surfaces have a primary view Surfaces belonging to a screen-casted window should always be considered visible even if they are not visible on any stage view - be it because they are on a different workspace, minimized or occluded. Doing this in an optimal fashion is highly complex right now - interdependent with (and somewhat similar to) ClutterClones. Thus treat stream-casted surfaces similar to those with clones, with the small difference that even a fully invisible surface still gets a primary view - the fastest one. This ensures that clients never refresh too slow for a screen-cast, at the cost of sometimes refreshing too fast. The later only happens on certain multi-monitor setups and should thus be acceptable. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2789>
2023-02-11 06:03:43 +00:00
#include "compositor/meta-window-actor-private.h"
Clean up include macros mess The order and way include macros were structured was chaotic, with no real common thread between files. Try to tidy up the mess with some common scheme, to make things look less messy.
2018-07-10 08:36:24 +00:00
#include "compositor/region-utils.h"
wayland: Fix calculation of window geometry when scaled Take the surface actor scale into account when calculating the window geometry. https://bugzilla.gnome.org/show_bug.cgi?id=744934
2015-03-25 09:18:35 +00:00
#include "wayland/meta-wayland-buffer.h"
Don't include wayland/ by default either
2014-03-19 02:01:31 +00:00
#include "wayland/meta-wayland-private.h"
surface-actor/wayland: Implement stable size and position rounding Implement the stable rounding algorithm as described in the discussions for the fractional-scale-v1 protocol. This adds an override of the ClutterActor::apply_transform vfunc for MetaSurfaceActorWayland that ensures the size and position of the contents of the surface are rounded according to the stable rounding algorithm. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2726>
2022-11-26 11:33:46 +00:00
#include "wayland/meta-wayland-subsurface.h"
wayland: Factor out some parts of meta_surface_actor_wayland_get_scale Put a toplevel window getter in meta-wayland-surface.h and a main monitor scale getter in window-wayland.h. https://bugzilla.gnome.org/show_bug.cgi?id=745655
2015-03-23 13:10:20 +00:00
#include "wayland/meta-window-wayland.h"
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
Use G_DECLARE_DERIVABLE/FINAL_TYPE on some types This is only for types in the `Meta` namespace. * Clears up a lot of boilerplate * We get `g_autoptr` support for free
2018-10-31 10:47:17 +00:00
struct _MetaSurfaceActorWayland
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
{
Use G_DECLARE_DERIVABLE/FINAL_TYPE on some types This is only for types in the `Meta` namespace. * Clears up a lot of boilerplate * We get `g_autoptr` support for free
2018-10-31 10:47:17 +00:00
MetaSurfaceActor parent;
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
MetaWaylandSurface *surface;
Use G_DECLARE_DERIVABLE/FINAL_TYPE on some types This is only for types in the `Meta` namespace. * Clears up a lot of boilerplate * We get `g_autoptr` support for free
2018-10-31 10:47:17 +00:00
};
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
Use G_DECLARE_DERIVABLE/FINAL_TYPE on some types This is only for types in the `Meta` namespace. * Clears up a lot of boilerplate * We get `g_autoptr` support for free
2018-10-31 10:47:17 +00:00
G_DEFINE_TYPE (MetaSurfaceActorWayland,
meta_surface_actor_wayland,
META_TYPE_SURFACE_ACTOR)
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
static void
meta_surface_actor_wayland_process_damage (MetaSurfaceActor *actor,
surface-actor/wayland: Minor style fixes https://gitlab.gnome.org/GNOME/mutter/merge_requests/5 https://bugzilla.gnome.org/show_bug.cgi?id=791938
2017-12-22 06:19:38 +00:00
int x,
int y,
int width,
int height)
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
{
surface-actor: Move out some X11-ism to X11 subclass On X11 we don't update the texture in certain circumstances, such as if the surface is a fullscreen unredirect, or doesn't have a Pixmap. On Wayland we only want to avoid updating the texture if there is no texture, but as this is handled implicitly by MetashapedTexture, we don't need to try to emulate the X11-y conditions in the generic layer and instead just have the implementations handle update processing themself. This doesn't have any functional changes, but removes a vfunc from MetaSurfaceActorClass. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1218
2020-04-24 21:21:26 +00:00
meta_surface_actor_update_area (actor, x, y, width, height);
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
}
static gboolean
window-actor: Move shapes, shadows and unredirection to X11 sub types Move out updating of various shapes (input, opaque, shape) indirectly from X11 to the corresponding X11 sub types of MetaWindowActor and MetaSurfaceActor. Also move fullscreen window unredirection code with it. We want to effectively do something similar for MetaCompositorServer, but it will work differently enough not to share too much logic. While it would have been nice to move things piece by piece, things were too intertwined to make it feasible. This has the side effect fixing accidentally and arbitrarily adding server side shadow to Wayland surfaces. Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/727 https://gitlab.gnome.org/GNOME/mutter/merge_requests/734
2019-08-17 08:00:46 +00:00
meta_surface_actor_wayland_is_opaque (MetaSurfaceActor *actor)
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
{
window-actor: Move shapes, shadows and unredirection to X11 sub types Move out updating of various shapes (input, opaque, shape) indirectly from X11 to the corresponding X11 sub types of MetaWindowActor and MetaSurfaceActor. Also move fullscreen window unredirection code with it. We want to effectively do something similar for MetaCompositorServer, but it will work differently enough not to share too much logic. While it would have been nice to move things piece by piece, things were too intertwined to make it feasible. This has the side effect fixing accidentally and arbitrarily adding server side shadow to Wayland surfaces. Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/727 https://gitlab.gnome.org/GNOME/mutter/merge_requests/734
2019-08-17 08:00:46 +00:00
MetaShapedTexture *stex = meta_surface_actor_get_texture (actor);
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
window-actor: Move shapes, shadows and unredirection to X11 sub types Move out updating of various shapes (input, opaque, shape) indirectly from X11 to the corresponding X11 sub types of MetaWindowActor and MetaSurfaceActor. Also move fullscreen window unredirection code with it. We want to effectively do something similar for MetaCompositorServer, but it will work differently enough not to share too much logic. While it would have been nice to move things piece by piece, things were too intertwined to make it feasible. This has the side effect fixing accidentally and arbitrarily adding server side shadow to Wayland surfaces. Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/727 https://gitlab.gnome.org/GNOME/mutter/merge_requests/734
2019-08-17 08:00:46 +00:00
return meta_shaped_texture_is_opaque (stex);
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
}
cleanup: Fix various typos Using the typos cli app Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3169>
2023-08-09 23:44:52 +00:00
#define UNOBSCURED_THRESHOLD 0.1
surface-actor-wayland: Add API to pick a primary stage view Add a simple heuristic how to choose the primary stage view to drive events like frame callbacks for a given surface actor. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1468>
2020-10-22 21:13:26 +00:00
surface-actor-wayland: Clean up and optimize check for primary view Avoid some allocations, save some CPU cycles and make the code easier to read. Behaviourwise the only expected change is that now, if there are mapped clones, we unconditionally choose the view with the highest refresh rate the actor (or one of its clones) is on and don't check the obscurred region any more. Thus in some cases a client may receive a higher rate of frame callbacks when obscured on a faster view while a clone is present on a slower one. The assumption is that cases like this are relatively rare and that the reduction of code complexity, the reduction of allocations in `meta_surface_actor_is_obscured_on_stage_view()` whenever the actor is not fully obscured and has clones on other views, as well as generally fewer lookups and less code in most common cases, compensate for that. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2671>
2022-10-18 13:40:19 +00:00
gboolean
meta_surface_actor_wayland_is_view_primary (MetaSurfaceActor *actor,
ClutterStageView *stage_view)
surface-actor-wayland: Add API to pick a primary stage view Add a simple heuristic how to choose the primary stage view to drive events like frame callbacks for a given surface actor. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1468>
2020-10-22 21:13:26 +00:00
{
ClutterStageView *current_primary_view = NULL;
surface-actor-wayland: Optimize get_current_primary_view for single view In case we only have a single view (or there's only one view left to check and the actor is visible on previous views) we can take a short- cut, saving a region allocation and some calculations. While on it, declare float numbers in '.f' style to make them more recognizable. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1596>
2020-11-23 00:32:32 +00:00
float highest_refresh_rate = 0.f;
float biggest_unobscurred_fraction = 0.f;
surface-actor/wayland: Ensure screen-casted surfaces have a primary view Surfaces belonging to a screen-casted window should always be considered visible even if they are not visible on any stage view - be it because they are on a different workspace, minimized or occluded. Doing this in an optimal fashion is highly complex right now - interdependent with (and somewhat similar to) ClutterClones. Thus treat stream-casted surfaces similar to those with clones, with the small difference that even a fully invisible surface still gets a primary view - the fastest one. This ensures that clients never refresh too slow for a screen-cast, at the cost of sometimes refreshing too fast. The later only happens on certain multi-monitor setups and should thus be acceptable. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2789>
2023-02-11 06:03:43 +00:00
MetaWindowActor *window_actor;
gboolean is_streaming = FALSE;
surface-actor-wayland: Add API to pick a primary stage view Add a simple heuristic how to choose the primary stage view to drive events like frame callbacks for a given surface actor. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1468>
2020-10-22 21:13:26 +00:00
GList *l;
surface-actor/wayland: Ensure screen-casted surfaces have a primary view Surfaces belonging to a screen-casted window should always be considered visible even if they are not visible on any stage view - be it because they are on a different workspace, minimized or occluded. Doing this in an optimal fashion is highly complex right now - interdependent with (and somewhat similar to) ClutterClones. Thus treat stream-casted surfaces similar to those with clones, with the small difference that even a fully invisible surface still gets a primary view - the fastest one. This ensures that clients never refresh too slow for a screen-cast, at the cost of sometimes refreshing too fast. The later only happens on certain multi-monitor setups and should thus be acceptable. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2789>
2023-02-11 06:03:43 +00:00
window_actor = meta_window_actor_from_actor (CLUTTER_ACTOR (actor));
if (window_actor)
is_streaming = meta_window_actor_is_streaming (window_actor);
surface-actor-wayland: Clean up and optimize check for primary view Avoid some allocations, save some CPU cycles and make the code easier to read. Behaviourwise the only expected change is that now, if there are mapped clones, we unconditionally choose the view with the highest refresh rate the actor (or one of its clones) is on and don't check the obscurred region any more. Thus in some cases a client may receive a higher rate of frame callbacks when obscured on a faster view while a clone is present on a slower one. The assumption is that cases like this are relatively rare and that the reduction of code complexity, the reduction of allocations in `meta_surface_actor_is_obscured_on_stage_view()` whenever the actor is not fully obscured and has clones on other views, as well as generally fewer lookups and less code in most common cases, compensate for that. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2671>
2022-10-18 13:40:19 +00:00
surface-actor/wayland: Ensure screen-casted surfaces have a primary view Surfaces belonging to a screen-casted window should always be considered visible even if they are not visible on any stage view - be it because they are on a different workspace, minimized or occluded. Doing this in an optimal fashion is highly complex right now - interdependent with (and somewhat similar to) ClutterClones. Thus treat stream-casted surfaces similar to those with clones, with the small difference that even a fully invisible surface still gets a primary view - the fastest one. This ensures that clients never refresh too slow for a screen-cast, at the cost of sometimes refreshing too fast. The later only happens on certain multi-monitor setups and should thus be acceptable. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2789>
2023-02-11 06:03:43 +00:00
if (clutter_actor_has_mapped_clones (CLUTTER_ACTOR (actor)) || is_streaming)
surface-actor-wayland: Add API to pick a primary stage view Add a simple heuristic how to choose the primary stage view to drive events like frame callbacks for a given surface actor. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1468>
2020-10-22 21:13:26 +00:00
{
surface-actor-wayland: Clean up and optimize check for primary view Avoid some allocations, save some CPU cycles and make the code easier to read. Behaviourwise the only expected change is that now, if there are mapped clones, we unconditionally choose the view with the highest refresh rate the actor (or one of its clones) is on and don't check the obscurred region any more. Thus in some cases a client may receive a higher rate of frame callbacks when obscured on a faster view while a clone is present on a slower one. The assumption is that cases like this are relatively rare and that the reduction of code complexity, the reduction of allocations in `meta_surface_actor_is_obscured_on_stage_view()` whenever the actor is not fully obscured and has clones on other views, as well as generally fewer lookups and less code in most common cases, compensate for that. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2671>
2022-10-18 13:40:19 +00:00
ClutterStage *stage;
surface-actor/wayland: Ensure screen-casted surfaces have a primary view Surfaces belonging to a screen-casted window should always be considered visible even if they are not visible on any stage view - be it because they are on a different workspace, minimized or occluded. Doing this in an optimal fashion is highly complex right now - interdependent with (and somewhat similar to) ClutterClones. Thus treat stream-casted surfaces similar to those with clones, with the small difference that even a fully invisible surface still gets a primary view - the fastest one. This ensures that clients never refresh too slow for a screen-cast, at the cost of sometimes refreshing too fast. The later only happens on certain multi-monitor setups and should thus be acceptable. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2789>
2023-02-11 06:03:43 +00:00
ClutterStageView *fallback_view = NULL;
float fallback_refresh_rate = 0.0;
surface-actor-wayland: Add API to pick a primary stage view Add a simple heuristic how to choose the primary stage view to drive events like frame callbacks for a given surface actor. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1468>
2020-10-22 21:13:26 +00:00
surface-actor-wayland: Clean up and optimize check for primary view Avoid some allocations, save some CPU cycles and make the code easier to read. Behaviourwise the only expected change is that now, if there are mapped clones, we unconditionally choose the view with the highest refresh rate the actor (or one of its clones) is on and don't check the obscurred region any more. Thus in some cases a client may receive a higher rate of frame callbacks when obscured on a faster view while a clone is present on a slower one. The assumption is that cases like this are relatively rare and that the reduction of code complexity, the reduction of allocations in `meta_surface_actor_is_obscured_on_stage_view()` whenever the actor is not fully obscured and has clones on other views, as well as generally fewer lookups and less code in most common cases, compensate for that. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2671>
2022-10-18 13:40:19 +00:00
stage = CLUTTER_STAGE (clutter_actor_get_stage (CLUTTER_ACTOR (actor)));
for (l = clutter_stage_peek_stage_views (stage); l; l = l->next)
surface-actor-wayland: Add API to pick a primary stage view Add a simple heuristic how to choose the primary stage view to drive events like frame callbacks for a given surface actor. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1468>
2020-10-22 21:13:26 +00:00
{
surface-actor-wayland: Clean up and optimize check for primary view Avoid some allocations, save some CPU cycles and make the code easier to read. Behaviourwise the only expected change is that now, if there are mapped clones, we unconditionally choose the view with the highest refresh rate the actor (or one of its clones) is on and don't check the obscurred region any more. Thus in some cases a client may receive a higher rate of frame callbacks when obscured on a faster view while a clone is present on a slower one. The assumption is that cases like this are relatively rare and that the reduction of code complexity, the reduction of allocations in `meta_surface_actor_is_obscured_on_stage_view()` whenever the actor is not fully obscured and has clones on other views, as well as generally fewer lookups and less code in most common cases, compensate for that. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2671>
2022-10-18 13:40:19 +00:00
ClutterStageView *view = l->data;
float refresh_rate;
refresh_rate = clutter_stage_view_get_refresh_rate (view);
surface-actor/wayland: Ensure screen-casted surfaces have a primary view Surfaces belonging to a screen-casted window should always be considered visible even if they are not visible on any stage view - be it because they are on a different workspace, minimized or occluded. Doing this in an optimal fashion is highly complex right now - interdependent with (and somewhat similar to) ClutterClones. Thus treat stream-casted surfaces similar to those with clones, with the small difference that even a fully invisible surface still gets a primary view - the fastest one. This ensures that clients never refresh too slow for a screen-cast, at the cost of sometimes refreshing too fast. The later only happens on certain multi-monitor setups and should thus be acceptable. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2789>
2023-02-11 06:03:43 +00:00
if (clutter_actor_is_effectively_on_stage_view (CLUTTER_ACTOR (actor),
view))
surface-actor-wayland: Optimize get_current_primary_view for single view In case we only have a single view (or there's only one view left to check and the actor is visible on previous views) we can take a short- cut, saving a region allocation and some calculations. While on it, declare float numbers in '.f' style to make them more recognizable. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1596>
2020-11-23 00:32:32 +00:00
{
surface-actor/wayland: Ensure screen-casted surfaces have a primary view Surfaces belonging to a screen-casted window should always be considered visible even if they are not visible on any stage view - be it because they are on a different workspace, minimized or occluded. Doing this in an optimal fashion is highly complex right now - interdependent with (and somewhat similar to) ClutterClones. Thus treat stream-casted surfaces similar to those with clones, with the small difference that even a fully invisible surface still gets a primary view - the fastest one. This ensures that clients never refresh too slow for a screen-cast, at the cost of sometimes refreshing too fast. The later only happens on certain multi-monitor setups and should thus be acceptable. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2789>
2023-02-11 06:03:43 +00:00
if (refresh_rate > highest_refresh_rate)
{
current_primary_view = view;
highest_refresh_rate = refresh_rate;
}
}
else
{
if (refresh_rate > fallback_refresh_rate)
{
fallback_view = view;
fallback_refresh_rate = refresh_rate;
}
surface-actor-wayland: Optimize get_current_primary_view for single view In case we only have a single view (or there's only one view left to check and the actor is visible on previous views) we can take a short- cut, saving a region allocation and some calculations. While on it, declare float numbers in '.f' style to make them more recognizable. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1596>
2020-11-23 00:32:32 +00:00
}
surface-actor-wayland: Add API to pick a primary stage view Add a simple heuristic how to choose the primary stage view to drive events like frame callbacks for a given surface actor. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1468>
2020-10-22 21:13:26 +00:00
}
surface-actor/wayland: Ensure screen-casted surfaces have a primary view Surfaces belonging to a screen-casted window should always be considered visible even if they are not visible on any stage view - be it because they are on a different workspace, minimized or occluded. Doing this in an optimal fashion is highly complex right now - interdependent with (and somewhat similar to) ClutterClones. Thus treat stream-casted surfaces similar to those with clones, with the small difference that even a fully invisible surface still gets a primary view - the fastest one. This ensures that clients never refresh too slow for a screen-cast, at the cost of sometimes refreshing too fast. The later only happens on certain multi-monitor setups and should thus be acceptable. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2789>
2023-02-11 06:03:43 +00:00
if (current_primary_view)
return current_primary_view == stage_view;
else if (is_streaming)
return fallback_view == stage_view;
surface-actor-wayland: Clean up and optimize check for primary view Avoid some allocations, save some CPU cycles and make the code easier to read. Behaviourwise the only expected change is that now, if there are mapped clones, we unconditionally choose the view with the highest refresh rate the actor (or one of its clones) is on and don't check the obscurred region any more. Thus in some cases a client may receive a higher rate of frame callbacks when obscured on a faster view while a clone is present on a slower one. The assumption is that cases like this are relatively rare and that the reduction of code complexity, the reduction of allocations in `meta_surface_actor_is_obscured_on_stage_view()` whenever the actor is not fully obscured and has clones on other views, as well as generally fewer lookups and less code in most common cases, compensate for that. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2671>
2022-10-18 13:40:19 +00:00
}
l = clutter_actor_peek_stage_views (CLUTTER_ACTOR (actor));
surface-actor/wayland: Ensure screen-casted surfaces have a primary view Surfaces belonging to a screen-casted window should always be considered visible even if they are not visible on any stage view - be it because they are on a different workspace, minimized or occluded. Doing this in an optimal fashion is highly complex right now - interdependent with (and somewhat similar to) ClutterClones. Thus treat stream-casted surfaces similar to those with clones, with the small difference that even a fully invisible surface still gets a primary view - the fastest one. This ensures that clients never refresh too slow for a screen-cast, at the cost of sometimes refreshing too fast. The later only happens on certain multi-monitor setups and should thus be acceptable. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2789>
2023-02-11 06:03:43 +00:00
if (!l)
return FALSE;
surface-actor-wayland: Clean up and optimize check for primary view Avoid some allocations, save some CPU cycles and make the code easier to read. Behaviourwise the only expected change is that now, if there are mapped clones, we unconditionally choose the view with the highest refresh rate the actor (or one of its clones) is on and don't check the obscurred region any more. Thus in some cases a client may receive a higher rate of frame callbacks when obscured on a faster view while a clone is present on a slower one. The assumption is that cases like this are relatively rare and that the reduction of code complexity, the reduction of allocations in `meta_surface_actor_is_obscured_on_stage_view()` whenever the actor is not fully obscured and has clones on other views, as well as generally fewer lookups and less code in most common cases, compensate for that. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2671>
2022-10-18 13:40:19 +00:00
if (!l->next)
{
surface-actor/wayland: Ensure screen-casted surfaces have a primary view Surfaces belonging to a screen-casted window should always be considered visible even if they are not visible on any stage view - be it because they are on a different workspace, minimized or occluded. Doing this in an optimal fashion is highly complex right now - interdependent with (and somewhat similar to) ClutterClones. Thus treat stream-casted surfaces similar to those with clones, with the small difference that even a fully invisible surface still gets a primary view - the fastest one. This ensures that clients never refresh too slow for a screen-cast, at the cost of sometimes refreshing too fast. The later only happens on certain multi-monitor setups and should thus be acceptable. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2789>
2023-02-11 06:03:43 +00:00
return !meta_surface_actor_is_obscured_on_stage_view (actor,
stage_view,
NULL);
surface-actor-wayland: Clean up and optimize check for primary view Avoid some allocations, save some CPU cycles and make the code easier to read. Behaviourwise the only expected change is that now, if there are mapped clones, we unconditionally choose the view with the highest refresh rate the actor (or one of its clones) is on and don't check the obscurred region any more. Thus in some cases a client may receive a higher rate of frame callbacks when obscured on a faster view while a clone is present on a slower one. The assumption is that cases like this are relatively rare and that the reduction of code complexity, the reduction of allocations in `meta_surface_actor_is_obscured_on_stage_view()` whenever the actor is not fully obscured and has clones on other views, as well as generally fewer lookups and less code in most common cases, compensate for that. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2671>
2022-10-18 13:40:19 +00:00
}
for (; l; l = l->next)
{
ClutterStageView *view = l->data;
float refresh_rate;
float unobscurred_fraction;
if (meta_surface_actor_is_obscured_on_stage_view (actor,
view,
&unobscurred_fraction))
continue;
refresh_rate = clutter_stage_view_get_refresh_rate (view);
surface-actor-wayland: Add API to pick a primary stage view Add a simple heuristic how to choose the primary stage view to drive events like frame callbacks for a given surface actor. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1468>
2020-10-22 21:13:26 +00:00
if ((refresh_rate > highest_refresh_rate &&
cleanup: Fix various typos Using the typos cli app Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3169>
2023-08-09 23:44:52 +00:00
(biggest_unobscurred_fraction < UNOBSCURED_THRESHOLD ||
unobscurred_fraction > UNOBSCURED_THRESHOLD)) ||
(biggest_unobscurred_fraction < UNOBSCURED_THRESHOLD &&
unobscurred_fraction > UNOBSCURED_THRESHOLD))
surface-actor-wayland: Add API to pick a primary stage view Add a simple heuristic how to choose the primary stage view to drive events like frame callbacks for a given surface actor. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1468>
2020-10-22 21:13:26 +00:00
{
surface-actor-wayland: Clean up and optimize check for primary view Avoid some allocations, save some CPU cycles and make the code easier to read. Behaviourwise the only expected change is that now, if there are mapped clones, we unconditionally choose the view with the highest refresh rate the actor (or one of its clones) is on and don't check the obscurred region any more. Thus in some cases a client may receive a higher rate of frame callbacks when obscured on a faster view while a clone is present on a slower one. The assumption is that cases like this are relatively rare and that the reduction of code complexity, the reduction of allocations in `meta_surface_actor_is_obscured_on_stage_view()` whenever the actor is not fully obscured and has clones on other views, as well as generally fewer lookups and less code in most common cases, compensate for that. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2671>
2022-10-18 13:40:19 +00:00
current_primary_view = view;
surface-actor-wayland: Add API to pick a primary stage view Add a simple heuristic how to choose the primary stage view to drive events like frame callbacks for a given surface actor. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1468>
2020-10-22 21:13:26 +00:00
highest_refresh_rate = refresh_rate;
biggest_unobscurred_fraction = unobscurred_fraction;
}
}
surface-actor-wayland: Clean up and optimize check for primary view Avoid some allocations, save some CPU cycles and make the code easier to read. Behaviourwise the only expected change is that now, if there are mapped clones, we unconditionally choose the view with the highest refresh rate the actor (or one of its clones) is on and don't check the obscurred region any more. Thus in some cases a client may receive a higher rate of frame callbacks when obscured on a faster view while a clone is present on a slower one. The assumption is that cases like this are relatively rare and that the reduction of code complexity, the reduction of allocations in `meta_surface_actor_is_obscured_on_stage_view()` whenever the actor is not fully obscured and has clones on other views, as well as generally fewer lookups and less code in most common cases, compensate for that. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2671>
2022-10-18 13:40:19 +00:00
return current_primary_view == stage_view;
surface-actor-wayland: Add API to pick a primary stage view Add a simple heuristic how to choose the primary stage view to drive events like frame callbacks for a given surface actor. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1468>
2020-10-22 21:13:26 +00:00
}
surface-actor/wayland: Implement stable size and position rounding Implement the stable rounding algorithm as described in the discussions for the fractional-scale-v1 protocol. This adds an override of the ClutterActor::apply_transform vfunc for MetaSurfaceActorWayland that ensures the size and position of the contents of the surface are rounded according to the stable rounding algorithm. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2726>
2022-11-26 11:33:46 +00:00
static void
meta_surface_actor_wayland_apply_transform (ClutterActor *actor,
graphene_matrix_t *matrix)
{
MetaSurfaceActorWayland *self = META_SURFACE_ACTOR_WAYLAND (actor);
ClutterActorClass *parent_class =
CLUTTER_ACTOR_CLASS (meta_surface_actor_wayland_parent_class);
MetaWaylandSurface *surface = meta_surface_actor_wayland_get_surface (self);
MetaWaylandSurface *root_surface;
MetaWindow *window;
MetaLogicalMonitor *logical_monitor;
surface-actor-wayland: Fix leak in apply_transform() Using g_object_get() to get the allocation creates a copy that needs to be freed by the caller. Fixes: e94b52777 ("surface-actor/wayland: Implement stable size and position rounding") Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3188>
2023-08-16 19:08:23 +00:00
g_autoptr (ClutterActorBox) allocation = NULL;
surface-actor/wayland: Implement stable size and position rounding Implement the stable rounding algorithm as described in the discussions for the fractional-scale-v1 protocol. This adds an override of the ClutterActor::apply_transform vfunc for MetaSurfaceActorWayland that ensures the size and position of the contents of the surface are rounded according to the stable rounding algorithm. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2726>
2022-11-26 11:33:46 +00:00
float scale;
float actor_width, actor_height;
float adj_actor_width, adj_actor_height;
float adj_actor_x, adj_actor_y;
float width_scale, height_scale;
float x_off, y_off;
if (!surface)
goto out;
root_surface = surface;
wayland/surface: Rename output/protocol_state to applied/committed_state This is more consistent with Wayland protocol spec language. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3395>
2023-11-14 10:44:05 +00:00
while (root_surface->applied_state.parent)
root_surface = root_surface->applied_state.parent;
surface-actor/wayland: Implement stable size and position rounding Implement the stable rounding algorithm as described in the discussions for the fractional-scale-v1 protocol. This adds an override of the ClutterActor::apply_transform vfunc for MetaSurfaceActorWayland that ensures the size and position of the contents of the surface are rounded according to the stable rounding algorithm. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2726>
2022-11-26 11:33:46 +00:00
window = meta_wayland_surface_get_window (root_surface);
if (!window)
goto out;
if (!META_IS_WINDOW_WAYLAND (window))
goto out;
logical_monitor = meta_window_get_highest_scale_monitor (window);
if (!logical_monitor)
goto out;
scale = meta_logical_monitor_get_scale (logical_monitor);
g_object_get (actor, "allocation", &allocation, NULL);
actor_width = clutter_actor_box_get_width (allocation);
actor_height = clutter_actor_box_get_height (allocation);
if (actor_width == 0.0 || actor_height == 0.0)
goto out;
/* We rely on MetaSurfaceActorContainerWayland to ensure that the toplevel
* surface on-display position is aligned to the physical pixel boundary.
*/
if (META_IS_WAYLAND_SUBSURFACE (surface->role))
{
adj_actor_width =
roundf ((surface->sub.x + actor_width) * scale) / scale -
roundf (surface->sub.x * scale) / scale;
adj_actor_height =
roundf ((surface->sub.y + actor_height) * scale) / scale -
roundf (surface->sub.y * scale) / scale;
adj_actor_x = adj_actor_y = 0.0;
do
{
adj_actor_x += roundf (surface->sub.x * scale) / scale;
adj_actor_y += roundf (surface->sub.y * scale) / scale;
wayland/surface: Rename output/protocol_state to applied/committed_state This is more consistent with Wayland protocol spec language. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3395>
2023-11-14 10:44:05 +00:00
surface = surface->applied_state.parent;
surface-actor/wayland: Implement stable size and position rounding Implement the stable rounding algorithm as described in the discussions for the fractional-scale-v1 protocol. This adds an override of the ClutterActor::apply_transform vfunc for MetaSurfaceActorWayland that ensures the size and position of the contents of the surface are rounded according to the stable rounding algorithm. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2726>
2022-11-26 11:33:46 +00:00
}
while (surface);
}
else
{
adj_actor_width = roundf (actor_width * scale) / scale;
adj_actor_height = roundf (actor_height * scale) / scale;
adj_actor_x = allocation->x1;
adj_actor_y = allocation->y1;
}
width_scale = adj_actor_width / actor_width;
height_scale = adj_actor_height / actor_height;
if (!G_APPROX_VALUE (width_scale, 1.0, FLT_EPSILON) ||
!G_APPROX_VALUE (height_scale, 1.0, FLT_EPSILON))
graphene_matrix_scale (matrix, width_scale, height_scale, 1.0);
parent_class->apply_transform (actor, matrix);
x_off = adj_actor_x - allocation->x1;
y_off = adj_actor_y - allocation->y1;
if (!G_APPROX_VALUE (x_off, 0.0, FLT_EPSILON) ||
!G_APPROX_VALUE (y_off, 0.0, FLT_EPSILON))
graphene_matrix_translate (matrix, &GRAPHENE_POINT3D_INIT (x_off, y_off, 0.0));
return;
out:
parent_class->apply_transform (actor, matrix);
}
surface-actor-wayland: Make sure to clean up on dispose We need to remove our destroy handler if the surface is destroyed before the buffer is, which is the case when we have no destroy effect.
2014-03-25 15:59:52 +00:00
static void
meta_surface_actor_wayland_dispose (GObject *object)
{
MetaSurfaceActorWayland *self = META_SURFACE_ACTOR_WAYLAND (object);
surface-actor-wayland: Handle stex being disposed As the MetaShapedTexture might already got finalized, this can lead to a crash. https://gitlab.gnome.org/GNOME/mutter/merge_requests/755
2019-06-30 13:03:32 +00:00
MetaShapedTexture *stex;
stex = meta_surface_actor_get_texture (META_SURFACE_ACTOR (self));
if (stex)
meta_shaped_texture_set_texture (stex, NULL);
surface-actor-wayland: Make sure to clean up on dispose We need to remove our destroy handler if the surface is destroyed before the buffer is, which is the case when we have no destroy effect.
2014-03-25 15:59:52 +00:00
Use G_DECLARE_DERIVABLE/FINAL_TYPE on some types This is only for types in the `Meta` namespace. * Clears up a lot of boilerplate * We get `g_autoptr` support for free
2018-10-31 10:47:17 +00:00
if (self->surface)
MetaSurfaceActorWayland: Use weak pointer instead of destroy hook MetaWaylandSurface is a GObject now, so lets utilize that. https://bugzilla.gnome.org/show_bug.cgi?id=763431
2016-01-18 08:59:45 +00:00
{
Use G_DECLARE_DERIVABLE/FINAL_TYPE on some types This is only for types in the `Meta` namespace. * Clears up a lot of boilerplate * We get `g_autoptr` support for free
2018-10-31 10:47:17 +00:00
g_object_remove_weak_pointer (G_OBJECT (self->surface),
(gpointer *) &self->surface);
self->surface = NULL;
MetaSurfaceActorWayland: Use weak pointer instead of destroy hook MetaWaylandSurface is a GObject now, so lets utilize that. https://bugzilla.gnome.org/show_bug.cgi?id=763431
2016-01-18 08:59:45 +00:00
}
surface-actor-wayland: Make sure to clean up on dispose We need to remove our destroy handler if the surface is destroyed before the buffer is, which is the case when we have no destroy effect.
2014-03-25 15:59:52 +00:00
G_OBJECT_CLASS (meta_surface_actor_wayland_parent_class)->dispose (object);
}
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
static void
meta_surface_actor_wayland_class_init (MetaSurfaceActorWaylandClass *klass)
{
MetaSurfaceActorClass *surface_actor_class = META_SURFACE_ACTOR_CLASS (klass);
surface-actor/wayland: Implement stable size and position rounding Implement the stable rounding algorithm as described in the discussions for the fractional-scale-v1 protocol. This adds an override of the ClutterActor::apply_transform vfunc for MetaSurfaceActorWayland that ensures the size and position of the contents of the surface are rounded according to the stable rounding algorithm. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2726>
2022-11-26 11:33:46 +00:00
ClutterActorClass *actor_class = CLUTTER_ACTOR_CLASS (klass);
surface-actor-wayland: Make sure to clean up on dispose We need to remove our destroy handler if the surface is destroyed before the buffer is, which is the case when we have no destroy effect.
2014-03-25 15:59:52 +00:00
GObjectClass *object_class = G_OBJECT_CLASS (klass);
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
surface_actor_class->process_damage = meta_surface_actor_wayland_process_damage;
window-actor: Move shapes, shadows and unredirection to X11 sub types Move out updating of various shapes (input, opaque, shape) indirectly from X11 to the corresponding X11 sub types of MetaWindowActor and MetaSurfaceActor. Also move fullscreen window unredirection code with it. We want to effectively do something similar for MetaCompositorServer, but it will work differently enough not to share too much logic. While it would have been nice to move things piece by piece, things were too intertwined to make it feasible. This has the side effect fixing accidentally and arbitrarily adding server side shadow to Wayland surfaces. Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/727 https://gitlab.gnome.org/GNOME/mutter/merge_requests/734
2019-08-17 08:00:46 +00:00
surface_actor_class->is_opaque = meta_surface_actor_wayland_is_opaque;
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-27 01:21:51 +00:00
surface-actor/wayland: Implement stable size and position rounding Implement the stable rounding algorithm as described in the discussions for the fractional-scale-v1 protocol. This adds an override of the ClutterActor::apply_transform vfunc for MetaSurfaceActorWayland that ensures the size and position of the contents of the surface are rounded according to the stable rounding algorithm. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2726>
2022-11-26 11:33:46 +00:00
actor_class->apply_transform = meta_surface_actor_wayland_apply_transform;
surface-actor-wayland: Make sure to clean up on dispose We need to remove our destroy handler if the surface is destroyed before the buffer is, which is the case when we have no destroy effect.
2014-03-25 15:59:52 +00:00
object_class->dispose = meta_surface_actor_wayland_dispose;
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
}
static void
meta_surface_actor_wayland_init (MetaSurfaceActorWayland *self)
{
}
MetaSurfaceActor *
meta_surface_actor_wayland_new (MetaWaylandSurface *surface)
{
MetaSurfaceActorWayland *self = g_object_new (META_TYPE_SURFACE_ACTOR_WAYLAND, NULL);
g_assert (meta_is_wayland_compositor ());
Use G_DECLARE_DERIVABLE/FINAL_TYPE on some types This is only for types in the `Meta` namespace. * Clears up a lot of boilerplate * We get `g_autoptr` support for free
2018-10-31 10:47:17 +00:00
self->surface = surface;
g_object_add_weak_pointer (G_OBJECT (self->surface),
(gpointer *) &self->surface);
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
return META_SURFACE_ACTOR (self);
}
MetaWaylandSurface *
meta_surface_actor_wayland_get_surface (MetaSurfaceActorWayland *self)
{
Use G_DECLARE_DERIVABLE/FINAL_TYPE on some types This is only for types in the `Meta` namespace. * Clears up a lot of boilerplate * We get `g_autoptr` support for free
2018-10-31 10:47:17 +00:00
return self->surface;
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 22:21:11 +00:00
}
Copy permalink