isa/mutter
1
0
Fork 0
mirror of https://github.com/brl/mutter.git synced 2024-11-28 02:50:41 -05:00
Code Issues Packages Projects Releases Wiki Activity
92f4ffc0dd
mutter/src/compositor/meta-surface-actor-wayland.c

255 lines
8.3 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 17:21:11 -05: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
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
* 02111-1307, USA.
*
* Written by:
* Jasper St. Pierre <jstpierre@mecheye.net>
*/
#include "config.h"
#include "meta-surface-actor-wayland.h"
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 02:49:52 -05:00
#include <math.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
#include <cogl/cogl-wayland-server.h>
#include "meta-shaped-texture-private.h"
Don't include wayland/ by default either
2014-03-18 22:01:31 -04:00
monitor-manager: Move logical monitor into its own file https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-12 21:37:11 -05:00
#include "backends/meta-logical-monitor.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 05:18:35 -04:00
#include "wayland/meta-wayland-buffer.h"
Don't include wayland/ by default either
2014-03-18 22:01:31 -04:00
#include "wayland/meta-wayland-private.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 09:10:20 -04: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 17:21:11 -05:00
Add support for scaled logical monitor framebuffers This commit adds support for rendering onto enlarged per logical monitor framebuffers, using the scaled clutter stage views, for HiDPI enabled logical monitors. This works by scaling the mode of the monitors in a logical monitors by the scale, no longer relying on scaling the window actors and window geometry for making windows have the correct size on HiDPI monitors. It is disabled by default, as in automatically created configurations will still use the old mode. This is partly because Xwayland clients will not yet work good enough to make it feasible. To enable, add the 'scale-monitor-framebuffer' keyword to the org.gnome.mutter.experimental-features gsettings array. It is still possible to specify the mode via the new D-Bus API, which has been adapted. The adaptations to the D-Bus API means the caller need to be aware of how to position logical monitors on the stage grid. This depends on the 'layout-mode' property that is used (see the DisplayConfig D-Bus documentation). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-24 05:10:52 -05:00
#include "backends/meta-backend-private.h"
wayland: Make the surface actor set its own state Since the surface actor knows more about how it draws itself, instead of pushing texture state (buffer and scale), input region and opaque region from MetaWaylandSurface after having transformed into what the surface actor expects, make the surface actor set its own state given what state the Wayland surface is in. https://bugzilla.gnome.org/show_bug.cgi?id=744933
2015-03-02 09:56:35 -05:00
#include "compositor/region-utils.h"
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 01:19:38 -05:00
typedef struct _MetaSurfaceActorWaylandPrivate
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
{
MetaWaylandSurface *surface;
wayland: Only call frame callbacks when a surface gets drawn on screen The spec says: "A server should avoid signalling the frame callbacks if the surface is not visible in any way, e.g. the surface is off-screen, or completely obscured by other opaque surfaces." We actually do have the information to do that but we are always calling the frame callbacks in after_stage_paint. So fix that to only call when when the surface gets drawn on screen. https://bugzilla.gnome.org/show_bug.cgi?id=739163
2015-07-23 11:22:22 -04:00
struct wl_list frame_callback_list;
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 01:19:38 -05:00
} MetaSurfaceActorWaylandPrivate;
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/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 01:19:38 -05:00
G_DEFINE_TYPE_WITH_PRIVATE (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 17:21:11 -05: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 01:19:38 -05: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 17:21:11 -05:00
{
}
static void
meta_surface_actor_wayland_pre_paint (MetaSurfaceActor *actor)
{
}
static gboolean
meta_surface_actor_wayland_is_visible (MetaSurfaceActor *actor)
{
/* TODO: ensure that the buffer isn't NULL, implement
* wayland mapping semantics */
return TRUE;
}
static gboolean
meta_surface_actor_wayland_should_unredirect (MetaSurfaceActor *actor)
{
return FALSE;
}
static void
meta_surface_actor_wayland_set_unredirected (MetaSurfaceActor *actor,
gboolean unredirected)
{
/* Do nothing. In the future, we'll use KMS to set this
* up as a hardware overlay or something. */
}
static gboolean
meta_surface_actor_wayland_is_unredirected (MetaSurfaceActor *actor)
{
return FALSE;
}
wayland: Only call frame callbacks when a surface gets drawn on screen The spec says: "A server should avoid signalling the frame callbacks if the surface is not visible in any way, e.g. the surface is off-screen, or completely obscured by other opaque surfaces." We actually do have the information to do that but we are always calling the frame callbacks in after_stage_paint. So fix that to only call when when the surface gets drawn on screen. https://bugzilla.gnome.org/show_bug.cgi?id=739163
2015-07-23 11:22:22 -04:00
void
meta_surface_actor_wayland_add_frame_callbacks (MetaSurfaceActorWayland *self,
struct wl_list *frame_callbacks)
{
MetaSurfaceActorWaylandPrivate *priv = meta_surface_actor_wayland_get_instance_private (self);
wl_list_insert_list (&priv->frame_callback_list, frame_callbacks);
}
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
static MetaWindow *
meta_surface_actor_wayland_get_window (MetaSurfaceActor *actor)
{
MetaSurfaceActorWayland: Only NULL check surface on class vfuncs The only time the surface pointer (priv->surface) may be NULL is when the surface is unmanaged but still painting, possibly due to a unmap animation or the like, so only guard handle this situation in the entry points that may come from the stage painting. https://bugzilla.gnome.org/show_bug.cgi?id=763431
2016-01-18 03:56:27 -05:00
MetaSurfaceActorWayland *self = META_SURFACE_ACTOR_WAYLAND (actor);
MetaWaylandSurface *surface = meta_surface_actor_wayland_get_surface (self);
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
wayland: do not crash if the surface is gone If a queued event is being processed after the surface is destroyed, trying to access the window associated with the surface will lead to a segmentation fault. This patch avoids the crash by first checking if the surface is not null. https://bugzilla.gnome.org/show_bug.cgi?id=754715
2015-09-08 05:52:10 -04:00
if (!surface)
return NULL;
return surface->window;
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
}
wayland: Scale native surfaces for hidpi Scale surfaces based on output scale and the buffer scale set by them. We pick the scale factor of the monitor there are mostly on. We only handle native i.e non xwayland / legacy clients yet. https://bugzilla.gnome.org/show_bug.cgi?id=728902
2014-04-26 06:55:54 -04:00
static void
MetaSurfaceActorWayland: Only NULL check surface on class vfuncs The only time the surface pointer (priv->surface) may be NULL is when the surface is unmanaged but still painting, possibly due to a unmap animation or the like, so only guard handle this situation in the entry points that may come from the stage painting. https://bugzilla.gnome.org/show_bug.cgi?id=763431
2016-01-18 03:56:27 -05:00
meta_surface_actor_wayland_get_preferred_width (ClutterActor *actor,
wayland: Scale native surfaces for hidpi Scale surfaces based on output scale and the buffer scale set by them. We pick the scale factor of the monitor there are mostly on. We only handle native i.e non xwayland / legacy clients yet. https://bugzilla.gnome.org/show_bug.cgi?id=728902
2014-04-26 06:55:54 -04:00
gfloat for_height,
gfloat *min_width_p,
gfloat *natural_width_p)
{
MetaSurfaceActorWayland: Only NULL check surface on class vfuncs The only time the surface pointer (priv->surface) may be NULL is when the surface is unmanaged but still painting, possibly due to a unmap animation or the like, so only guard handle this situation in the entry points that may come from the stage painting. https://bugzilla.gnome.org/show_bug.cgi?id=763431
2016-01-18 03:56:27 -05:00
MetaSurfaceActorWayland *self = META_SURFACE_ACTOR_WAYLAND (actor);
MetaShapedTexture *stex;
double scale;
stex = meta_surface_actor_get_texture (META_SURFACE_ACTOR (self));
wayland: Push actor state instead of itself pulling Make the Wayland objects push the state relevant to their role to the MetaSurfaceActor instead of MetaSurfaceActorWayland pulling the state from the associated surface. This makes the relationship between the actor and the objects that constructs it more clear; the actor is a drawable that the protocol objects control, not the other way around. This will make it easier to "detach" a surface actor from a surface, which is necessary when unmapping a window while the underlying surface is yet to be destroyed and potentially reused. https://gitlab.gnome.org/GNOME/mutter/merge_requests/5 https://bugzilla.gnome.org/show_bug.cgi?id=791938
2017-12-22 01:28:28 -05:00
clutter_actor_get_scale (CLUTTER_ACTOR (stex), &scale, NULL);
MetaSurfaceActorWayland: Only NULL check surface on class vfuncs The only time the surface pointer (priv->surface) may be NULL is when the surface is unmanaged but still painting, possibly due to a unmap animation or the like, so only guard handle this situation in the entry points that may come from the stage painting. https://bugzilla.gnome.org/show_bug.cgi?id=763431
2016-01-18 03:56:27 -05:00
clutter_actor_get_preferred_width (CLUTTER_ACTOR (stex),
for_height,
min_width_p,
natural_width_p);
wayland: Scale native surfaces for hidpi Scale surfaces based on output scale and the buffer scale set by them. We pick the scale factor of the monitor there are mostly on. We only handle native i.e non xwayland / legacy clients yet. https://bugzilla.gnome.org/show_bug.cgi?id=728902
2014-04-26 06:55:54 -04:00
if (min_width_p)
*min_width_p *= scale;
if (natural_width_p)
*natural_width_p *= scale;
}
static void
MetaSurfaceActorWayland: Only NULL check surface on class vfuncs The only time the surface pointer (priv->surface) may be NULL is when the surface is unmanaged but still painting, possibly due to a unmap animation or the like, so only guard handle this situation in the entry points that may come from the stage painting. https://bugzilla.gnome.org/show_bug.cgi?id=763431
2016-01-18 03:56:27 -05:00
meta_surface_actor_wayland_get_preferred_height (ClutterActor *actor,
wayland: Scale native surfaces for hidpi Scale surfaces based on output scale and the buffer scale set by them. We pick the scale factor of the monitor there are mostly on. We only handle native i.e non xwayland / legacy clients yet. https://bugzilla.gnome.org/show_bug.cgi?id=728902
2014-04-26 06:55:54 -04:00
gfloat for_width,
gfloat *min_height_p,
gfloat *natural_height_p)
{
MetaSurfaceActorWayland: Only NULL check surface on class vfuncs The only time the surface pointer (priv->surface) may be NULL is when the surface is unmanaged but still painting, possibly due to a unmap animation or the like, so only guard handle this situation in the entry points that may come from the stage painting. https://bugzilla.gnome.org/show_bug.cgi?id=763431
2016-01-18 03:56:27 -05:00
MetaSurfaceActorWayland *self = META_SURFACE_ACTOR_WAYLAND (actor);
MetaShapedTexture *stex;
double scale;
stex = meta_surface_actor_get_texture (META_SURFACE_ACTOR (self));
wayland: Push actor state instead of itself pulling Make the Wayland objects push the state relevant to their role to the MetaSurfaceActor instead of MetaSurfaceActorWayland pulling the state from the associated surface. This makes the relationship between the actor and the objects that constructs it more clear; the actor is a drawable that the protocol objects control, not the other way around. This will make it easier to "detach" a surface actor from a surface, which is necessary when unmapping a window while the underlying surface is yet to be destroyed and potentially reused. https://gitlab.gnome.org/GNOME/mutter/merge_requests/5 https://bugzilla.gnome.org/show_bug.cgi?id=791938
2017-12-22 01:28:28 -05:00
clutter_actor_get_scale (CLUTTER_ACTOR (stex), NULL, &scale);
MetaSurfaceActorWayland: Only NULL check surface on class vfuncs The only time the surface pointer (priv->surface) may be NULL is when the surface is unmanaged but still painting, possibly due to a unmap animation or the like, so only guard handle this situation in the entry points that may come from the stage painting. https://bugzilla.gnome.org/show_bug.cgi?id=763431
2016-01-18 03:56:27 -05:00
clutter_actor_get_preferred_height (CLUTTER_ACTOR (stex),
for_width,
min_height_p,
natural_height_p);
wayland: Scale native surfaces for hidpi Scale surfaces based on output scale and the buffer scale set by them. We pick the scale factor of the monitor there are mostly on. We only handle native i.e non xwayland / legacy clients yet. https://bugzilla.gnome.org/show_bug.cgi?id=728902
2014-04-26 06:55:54 -04:00
if (min_height_p)
*min_height_p *= scale;
if (natural_height_p)
*natural_height_p *= scale;
}
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 02:49:52 -05:00
static void
meta_surface_actor_wayland_paint (ClutterActor *actor)
{
MetaSurfaceActorWayland *self = META_SURFACE_ACTOR_WAYLAND (actor);
MetaSurfaceActorWaylandPrivate *priv =
meta_surface_actor_wayland_get_instance_private (self);
if (priv->surface)
wayland: Only call frame callbacks when a surface gets drawn on screen The spec says: "A server should avoid signalling the frame callbacks if the surface is not visible in any way, e.g. the surface is off-screen, or completely obscured by other opaque surfaces." We actually do have the information to do that but we are always calling the frame callbacks in after_stage_paint. So fix that to only call when when the surface gets drawn on screen. https://bugzilla.gnome.org/show_bug.cgi?id=739163
2015-07-23 11:22:22 -04:00
{
MetaWaylandCompositor *compositor = priv->surface->compositor;
wl_list_insert_list (&compositor->frame_callbacks, &priv->frame_callback_list);
wl_list_init (&priv->frame_callback_list);
}
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 02:49:52 -05:00
CLUTTER_ACTOR_CLASS (meta_surface_actor_wayland_parent_class)->paint (actor);
}
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 11:59:52 -04:00
static void
meta_surface_actor_wayland_dispose (GObject *object)
{
MetaSurfaceActorWayland *self = META_SURFACE_ACTOR_WAYLAND (object);
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 03:59:45 -05:00
MetaSurfaceActorWaylandPrivate *priv =
meta_surface_actor_wayland_get_instance_private (self);
MetaWaylandFrameCallback *cb, *next;
MetaSurfaceActorWayland: Remove API never used externally anymore https://bugzilla.gnome.org/show_bug.cgi?id=773629
2016-10-20 03:48:12 -04:00
MetaShapedTexture *stex =
meta_surface_actor_get_texture (META_SURFACE_ACTOR (self));
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 11:59:52 -04:00
MetaSurfaceActorWayland: Remove API never used externally anymore https://bugzilla.gnome.org/show_bug.cgi?id=773629
2016-10-20 03:48:12 -04:00
meta_shaped_texture_set_texture (stex, 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 03:59:45 -05:00
if (priv->surface)
{
g_object_remove_weak_pointer (G_OBJECT (priv->surface),
(gpointer *) &priv->surface);
priv->surface = NULL;
}
wl_list_for_each_safe (cb, next, &priv->frame_callback_list, link)
wl_resource_destroy (cb->resource);
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 11:59:52 -04: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 17:21:11 -05:00
static void
meta_surface_actor_wayland_class_init (MetaSurfaceActorWaylandClass *klass)
{
MetaSurfaceActorClass *surface_actor_class = META_SURFACE_ACTOR_CLASS (klass);
wayland: Scale native surfaces for hidpi Scale surfaces based on output scale and the buffer scale set by them. We pick the scale factor of the monitor there are mostly on. We only handle native i.e non xwayland / legacy clients yet. https://bugzilla.gnome.org/show_bug.cgi?id=728902
2014-04-26 06:55:54 -04: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 11:59:52 -04: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 17:21:11 -05:00
wayland: Scale native surfaces for hidpi Scale surfaces based on output scale and the buffer scale set by them. We pick the scale factor of the monitor there are mostly on. We only handle native i.e non xwayland / legacy clients yet. https://bugzilla.gnome.org/show_bug.cgi?id=728902
2014-04-26 06:55:54 -04:00
actor_class->get_preferred_width = meta_surface_actor_wayland_get_preferred_width;
actor_class->get_preferred_height = meta_surface_actor_wayland_get_preferred_height;
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 02:49:52 -05:00
actor_class->paint = meta_surface_actor_wayland_paint;
wayland: Scale native surfaces for hidpi Scale surfaces based on output scale and the buffer scale set by them. We pick the scale factor of the monitor there are mostly on. We only handle native i.e non xwayland / legacy clients yet. https://bugzilla.gnome.org/show_bug.cgi?id=728902
2014-04-26 06:55:54 -04:00
window-actor: Split into two subclasses of MetaSurfaceActor The rendering logic before was somewhat complex. We had three independent cases to take into account when doing rendering: * X11 compositor. In this case, we're a traditional X11 compositor, not a Wayland compositor. We use XCompositeNameWindowPixmap to get the backing pixmap for the window, and deal with the COMPOSITE extension messiness. In this case, meta_is_wayland_compositor() is FALSE. * Wayland clients. In this case, we're a Wayland compositor managing Wayland surfaces. The rendering for this is fairly straightforward, as Cogl handles most of the complexity with EGL and SHM buffers... Wayland clients give us the input and opaque regions through wl_surface. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND. * XWayland clients. In this case, we're a Wayland compositor, like above, and XWayland hands us Wayland surfaces. XWayland handles the COMPOSITE extension messiness for us, and hands us a buffer like any other Wayland client. We have to fetch the input and opaque regions from the X11 window ourselves. In this case, meta_is_wayland_compositor() is TRUE and priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11. We now split the rendering logic into two subclasses, which are: * MetaSurfaceActorX11, which handles the X11 compositor case, in that it uses XCompositeNameWindowPixmap to get the backing pixmap, and deal with all the COMPOSITE extension messiness. * MetaSurfaceActorWayland, which handles the Wayland compositor case for both native Wayland clients and XWayland clients. XWayland handles COMPOSITE for us, and handles pushing a surface over through the xf86-video-wayland DDX. Frame sync is still in MetaWindowActor, as it needs to work for both the X11 compositor and XWayland client cases. When Wayland's video display protocol lands, this will need to be significantly overhauled, as it would have to work for any wl_surface, including subsurfaces, so we would need surface-level discretion. https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-01 17:21:11 -05:00
surface_actor_class->process_damage = meta_surface_actor_wayland_process_damage;
surface_actor_class->pre_paint = meta_surface_actor_wayland_pre_paint;
surface_actor_class->is_visible = meta_surface_actor_wayland_is_visible;
surface_actor_class->should_unredirect = meta_surface_actor_wayland_should_unredirect;
surface_actor_class->set_unredirected = meta_surface_actor_wayland_set_unredirected;
surface_actor_class->is_unredirected = meta_surface_actor_wayland_is_unredirected;
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
surface_actor_class->get_window = meta_surface_actor_wayland_get_window;
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 11:59:52 -04: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 17:21:11 -05: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);
MetaSurfaceActorWaylandPrivate *priv = meta_surface_actor_wayland_get_instance_private (self);
g_assert (meta_is_wayland_compositor ());
wayland: Only call frame callbacks when a surface gets drawn on screen The spec says: "A server should avoid signalling the frame callbacks if the surface is not visible in any way, e.g. the surface is off-screen, or completely obscured by other opaque surfaces." We actually do have the information to do that but we are always calling the frame callbacks in after_stage_paint. So fix that to only call when when the surface gets drawn on screen. https://bugzilla.gnome.org/show_bug.cgi?id=739163
2015-07-23 11:22:22 -04:00
wl_list_init (&priv->frame_callback_list);
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
priv->surface = 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 03:59:45 -05:00
g_object_add_weak_pointer (G_OBJECT (priv->surface),
(gpointer *) &priv->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 17:21:11 -05:00
return META_SURFACE_ACTOR (self);
}
MetaWaylandSurface *
meta_surface_actor_wayland_get_surface (MetaSurfaceActorWayland *self)
{
MetaSurfaceActorWaylandPrivate *priv = meta_surface_actor_wayland_get_instance_private (self);
return priv->surface;
}
Reference in New Issue Copy Permalink