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

110 lines
4.3 KiB
C
Raw Normal View History

Remove Mutter namespace prefix Move all objects and functions namespaced with Mutter into the Meta namespace to get a single consistent namespace. Changes that aren't simply changing mutter to meta: MutterWindow => MetaWindowActor mutter_get_windows => meta_get_window_actors mutter_plugin_get_windows => meta_plugin_get_window_actors https://bugzilla.gnome.org/show_bug.cgi?id=628520
2010-10-18 13:27:14 -04:00
/* -*- mode: C; c-file-style: "gnu"; indent-tabs-mode: nil; -*- */
#ifndef META_WINDOW_ACTOR_PRIVATE_H
#define 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 04:36:24 -04:00
#include "compositor/meta-plugin-manager.h"
#include "compositor/meta-surface-actor.h"
#include "meta/compositor-mutter.h"
Remove Mutter namespace prefix Move all objects and functions namespaced with Mutter into the Meta namespace to get a single consistent namespace. Changes that aren't simply changing mutter to meta: MutterWindow => MetaWindowActor mutter_get_windows => meta_get_window_actors mutter_plugin_get_windows => meta_plugin_get_window_actors https://bugzilla.gnome.org/show_bug.cgi?id=628520
2010-10-18 13:27:14 -04:00
window-actor: Turn into a derivable class We will introduce specialized MetaWindowActors for X11 and Wayland in the future, so it needs to be derivable. Make it a derivable class, and introduce a private field. The MetaWindowActorClass definition is in the private header in order to prevent external consumers of Mutter to create MetaWindowActor implementations of their own. That is, MetaWindowActor is only internally derivable. https://gitlab.gnome.org/GNOME/mutter/merge_requests/368
2018-12-21 15:12:49 -05:00
struct _MetaWindowActorClass
{
ClutterActorClass parent;
window-actor: Move X11-specific code to MetaWindowActorX11 MetaWindowActor handles sending _NET_WM_FRAME_* X atoms to clients - even pure Wayland clients. Now that we have Wayland- and X11-specific implementations of MetaWindowActor, we can delegate this to MetaWindowActorX11, and allow pure Wayland apps to not even connect to MetaSurfaceActor:repaint-scheduled. Do that by moving all the X11-specific code to the X11-specific MetaWindowActorX11 class. Add vfuncs to MetaWindowActorClass that are necessary for the move, namely: * pre_paint() and post_paint() * post_init() * frame_complete() * set_surface_actor() * queue_frame_drawn() https://gitlab.gnome.org/GNOME/mutter/merge_requests/368
2018-12-21 15:51:02 -05:00
void (*frame_complete) (MetaWindowActor *actor,
ClutterFrameInfo *frame_info,
int64_t presentation_time);
window-actor: Add API to get the surface actor candidate for scanout This replaces the API to get the topmost surface actor with an API to get the surface actor that could be a candidate for direct scanout. The advantage of this is that it allows X11 and Wayland specific restrictions for these actors. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2409>
2022-05-11 16:32:33 -04:00
MetaSurfaceActor * (*get_scanout_candidate) (MetaWindowActor *actor);
window-actor: Add API to get the topmost surface actor On Wayland a window actor may have more than one surface actor, most importantly when subsurfaces are used. Add a new function to request the one which is at the top - it will be used in the next commit. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2211>
2022-01-05 16:05:50 -05:00
window-actor: Make it clearer that the surface actor doesn't change The way code was structured made it easy to misunderstand things as the surface actor of a window actor could change over time. So is not the case, however, the intention of the corresponding "update" function was so that a surface actor could be assigned to a window actor as soon as the X11 window was associated with its corresponding wl_surface, if the window in question came from Xwayland. Restructure the code and internal API a bit to make it clear that a window actor only once gets a surface actor assigned to it, and that it after that point never changes. https://gitlab.gnome.org/GNOME/mutter/merge_requests/659
2019-06-27 13:33:24 -04:00
void (*assign_surface_actor) (MetaWindowActor *actor,
MetaSurfaceActor *surface_actor);
window-actor: Move X11-specific code to MetaWindowActorX11 MetaWindowActor handles sending _NET_WM_FRAME_* X atoms to clients - even pure Wayland clients. Now that we have Wayland- and X11-specific implementations of MetaWindowActor, we can delegate this to MetaWindowActorX11, and allow pure Wayland apps to not even connect to MetaSurfaceActor:repaint-scheduled. Do that by moving all the X11-specific code to the X11-specific MetaWindowActorX11 class. Add vfuncs to MetaWindowActorClass that are necessary for the move, namely: * pre_paint() and post_paint() * post_init() * frame_complete() * set_surface_actor() * queue_frame_drawn() https://gitlab.gnome.org/GNOME/mutter/merge_requests/368
2018-12-21 15:51:02 -05:00
void (*queue_frame_drawn) (MetaWindowActor *actor,
gboolean skip_sync_delay);
clutter: Paint views with individual frame clocks Replace the default master clock with multiple frame clocks, each driving its own stage view. As each stage view represents one CRTC, this means we draw each CRTC with its own designated frame clock, disconnected from all the others. For example this means we when using the native backend will never need to wait for one monitor to vsync before painting another, so e.g. having a 144 Hz monitor next to a 60 Hz monitor, things including both Wayland and X11 applications and shell UI will be able to render at the corresponding monitor refresh rate. This also changes a warning about missed frames when sending _NETWM_FRAME_TIMINGS messages to a debug log entry, as it's expected that we'll start missing frames e.g. when a X11 window (via Xwayland) is exclusively within a stage view that was not painted, while another one was, still increasing the global frame clock. Addititonally, this also requires the X11 window actor to schedule timeouts for _NET_WM_FRAME_DRAWN/_NET_WM_FRAME_TIMINGS event emitting, if the actor wasn't on any stage views, as now we'll only get the frame callbacks on actors when they actually were painted, while in the past, we'd invoke that vfunc when anything was painted. Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/903 Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3 https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
2020-05-29 18:27:56 -04:00
void (*before_paint) (MetaWindowActor *actor,
ClutterStageView *stage_view);
void (*after_paint) (MetaWindowActor *actor,
ClutterStageView *stage_view);
compositor: Use stage signals instead of clutter repaint callbacks The repaint callbacks are not tied to repaint, thus a bit misleading. What the functionality in the pre/post-paint callbacks here cares about is when actually painting; the non-painting related parts has already moved out to a *-update signal. This also renames the related MetaWindowActorClass vfuncs, to align with naming convention of the signals that it listens to. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
2020-05-29 18:02:42 -04:00
window-actor: Move X11-specific code to MetaWindowActorX11 MetaWindowActor handles sending _NET_WM_FRAME_* X atoms to clients - even pure Wayland clients. Now that we have Wayland- and X11-specific implementations of MetaWindowActor, we can delegate this to MetaWindowActorX11, and allow pure Wayland apps to not even connect to MetaSurfaceActor:repaint-scheduled. Do that by moving all the X11-specific code to the X11-specific MetaWindowActorX11 class. Add vfuncs to MetaWindowActorClass that are necessary for the move, namely: * pre_paint() and post_paint() * post_init() * frame_complete() * set_surface_actor() * queue_frame_drawn() https://gitlab.gnome.org/GNOME/mutter/merge_requests/368
2018-12-21 15:51:02 -05:00
void (*queue_destroy) (MetaWindowActor *actor);
window-actor: Add `set_frozen` vfunc Currently, the window actor freeze/thaw implementation sets the frozen state of the surface actor using `meta_surface_actor_set_frozen()`. If we want to expand that behavior to also freeze/thaw commits for X11 windows running on Xwayland, we need to have a specific vfunc to abstract that in the window actor specific implementation. https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
2019-12-09 09:06:58 -05:00
void (*set_frozen) (MetaWindowActor *actor,
gboolean frozen);
window-actor: Add API to update regions For X11 clients running on Xwayland, the opaque, input and shape regions are processed from different properties and may occur at a different time, before the actual buffer is eventually committed by Xwayland. Add a new API `update_regions` to window actor to trigger the update of those regions when needed. https://gitlab.gnome.org/GNOME/mutter/merge_requests/1091
2020-03-03 04:26:54 -05:00
void (*update_regions) (MetaWindowActor *actor);
window-actor: Add a new can_freeze_commits() API Mutter freezes Xwayland commits when resizing windows, and thaw them in the window actors' after_paint() for X11. Yet, after_paint() could be never called, as when a new window is mapped while the overview is active in gnome-shell. As a result, the content of the X11 window will remain invisible to the overview. Add a new window actor API to tell whether commits can be frozen. For Wayland window actors, this always return FALSE, whereas for X11 window actors, it checks whether the Clutter actor is mapped. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1678>
2021-01-22 10:26:17 -05:00
gboolean (*can_freeze_commits) (MetaWindowActor *actor);
window-actor: Turn into a derivable class We will introduce specialized MetaWindowActors for X11 and Wayland in the future, so it needs to be derivable. Make it a derivable class, and introduce a private field. The MetaWindowActorClass definition is in the private header in order to prevent external consumers of Mutter to create MetaWindowActor implementations of their own. That is, MetaWindowActor is only internally derivable. https://gitlab.gnome.org/GNOME/mutter/merge_requests/368
2018-12-21 15:12:49 -05:00
};
compositor: Don't emit size-changed when only position changes Waking up gnome-shell and triggering JavaScript listeners of `size-changed` every time a window was only moved was wasting a lot of CPU. This cuts the CPU requirement for dragging windows by around 22%. https://gitlab.gnome.org/GNOME/mutter/merge_requests/568
2019-05-07 06:08:13 -04:00
typedef enum
{
META_WINDOW_ACTOR_CHANGE_SIZE = 1 << 0,
META_WINDOW_ACTOR_CHANGE_POSITION = 1 << 1
} MetaWindowActorChanges;
window-actor: rename destroy function in queue_destroy Since this might delay the destruction after animation has succeeded, it's just better to rename this accordingly. https://bugzilla.gnome.org/show_bug.cgi?id=791006
2017-11-30 22:17:02 -05:00
void meta_window_actor_queue_destroy (MetaWindowActor *self);
Remove Mutter namespace prefix Move all objects and functions namespaced with Mutter into the Meta namespace to get a single consistent namespace. Changes that aren't simply changing mutter to meta: MutterWindow => MetaWindowActor mutter_get_windows => meta_get_window_actors mutter_plugin_get_windows => meta_plugin_get_window_actors https://bugzilla.gnome.org/show_bug.cgi?id=628520
2010-10-18 13:27:14 -04:00
void meta_window_actor_show (MetaWindowActor *self,
MetaCompEffect effect);
void meta_window_actor_hide (MetaWindowActor *self,
MetaCompEffect effect);
Implement a generic "size change" mechanism A much less hacky version of maximize / unmaximize is reimplemented in terms of this, but it could also eventually be used for fullscreen / unfullscreen, and tile / untile.
2015-07-06 00:08:08 -04:00
void meta_window_actor_size_change (MetaWindowActor *self,
MetaSizeChange which_change,
MetaRectangle *old_frame_rect,
MetaRectangle *old_buffer_rect);
Remove Mutter namespace prefix Move all objects and functions namespaced with Mutter into the Meta namespace to get a single consistent namespace. Changes that aren't simply changing mutter to meta: MutterWindow => MetaWindowActor mutter_get_windows => meta_get_window_actors mutter_plugin_get_windows => meta_plugin_get_window_actors https://bugzilla.gnome.org/show_bug.cgi?id=628520
2010-10-18 13:27:14 -04:00
clutter: Paint views with individual frame clocks Replace the default master clock with multiple frame clocks, each driving its own stage view. As each stage view represents one CRTC, this means we draw each CRTC with its own designated frame clock, disconnected from all the others. For example this means we when using the native backend will never need to wait for one monitor to vsync before painting another, so e.g. having a 144 Hz monitor next to a 60 Hz monitor, things including both Wayland and X11 applications and shell UI will be able to render at the corresponding monitor refresh rate. This also changes a warning about missed frames when sending _NETWM_FRAME_TIMINGS messages to a debug log entry, as it's expected that we'll start missing frames e.g. when a X11 window (via Xwayland) is exclusively within a stage view that was not painted, while another one was, still increasing the global frame clock. Addititonally, this also requires the X11 window actor to schedule timeouts for _NET_WM_FRAME_DRAWN/_NET_WM_FRAME_TIMINGS event emitting, if the actor wasn't on any stage views, as now we'll only get the frame callbacks on actors when they actually were painted, while in the past, we'd invoke that vfunc when anything was painted. Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/903 Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3 https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
2020-05-29 18:27:56 -04:00
void meta_window_actor_before_paint (MetaWindowActor *self,
ClutterStageView *stage_view);
void meta_window_actor_after_paint (MetaWindowActor *self,
ClutterStageView *stage_view);
Send _NET_WM_FRAME_TIMINGS messages We previously had timestamp information stubbed out in _NET_WM_FRAME_DRAWN. Instead of this, add a high-resolution timestamp in _NET_WM_FRAME_DRAWN then send a _NET_WM_FRAME_TIMINGS message after when we have complete frame timing information, representing the "presentation time" of the frame as an offset from the timestamp in _NET_WM_FRAME_DRAWN. To provide maximum space in the messages,_NET_WM_FRAME_DRAWN and _NET_WM_FRAME_TIMINGS are not done as WM_PROTOCOLS messages but have their own message types. https://bugzilla.gnome.org/show_bug.cgi?id=685463
2012-11-12 14:11:08 -05:00
void meta_window_actor_frame_complete (MetaWindowActor *self,
Use signals instead of onscreen framebuffer frame callbacks CoglFrameInfo is a frame info container associated with a single onscreen framebuffer. The clutter stage will eventually support drawing a stage frame with multiple onscreen framebuffers, thus needs its own frame info container. This patch introduces a new stage signal 'presented' and a accompaning ClutterFrameInfo and adapts the stage windows and past onscreen frame callbacks users to use the signal and new info container. https://bugzilla.gnome.org/show_bug.cgi?id=768976
2016-06-08 01:07:09 -04:00
ClutterFrameInfo *frame_info,
Send _NET_WM_FRAME_TIMINGS messages We previously had timestamp information stubbed out in _NET_WM_FRAME_DRAWN. Instead of this, add a high-resolution timestamp in _NET_WM_FRAME_DRAWN then send a _NET_WM_FRAME_TIMINGS message after when we have complete frame timing information, representing the "presentation time" of the frame as an offset from the timestamp in _NET_WM_FRAME_DRAWN. To provide maximum space in the messages,_NET_WM_FRAME_DRAWN and _NET_WM_FRAME_TIMINGS are not done as WM_PROTOCOLS messages but have their own message types. https://bugzilla.gnome.org/show_bug.cgi?id=685463
2012-11-12 14:11:08 -05:00
gint64 presentation_time);
Remove Mutter namespace prefix Move all objects and functions namespaced with Mutter into the Meta namespace to get a single consistent namespace. Changes that aren't simply changing mutter to meta: MutterWindow => MetaWindowActor mutter_get_windows => meta_get_window_actors mutter_plugin_get_windows => meta_plugin_get_window_actors https://bugzilla.gnome.org/show_bug.cgi?id=628520
2010-10-18 13:27:14 -04:00
gboolean meta_window_actor_effect_in_progress (MetaWindowActor *self);
compositor: Don't emit size-changed when only position changes Waking up gnome-shell and triggering JavaScript listeners of `size-changed` every time a window was only moved was wasting a lot of CPU. This cuts the CPU requirement for dragging windows by around 22%. https://gitlab.gnome.org/GNOME/mutter/merge_requests/568
2019-05-07 06:08:13 -04:00
MetaWindowActorChanges meta_window_actor_sync_actor_geometry (MetaWindowActor *self,
gboolean did_placement);
Remove Mutter namespace prefix Move all objects and functions namespaced with Mutter into the Meta namespace to get a single consistent namespace. Changes that aren't simply changing mutter to meta: MutterWindow => MetaWindowActor mutter_get_windows => meta_get_window_actors mutter_plugin_get_windows => meta_plugin_get_window_actors https://bugzilla.gnome.org/show_bug.cgi?id=628520
2010-10-18 13:27:14 -04:00
void meta_window_actor_update_opacity (MetaWindowActor *self);
void meta_window_actor_mapped (MetaWindowActor *self);
void meta_window_actor_unmapped (MetaWindowActor *self);
compositor: Simplify meta_window_actor_set_updates_frozen Since we always call it with the same value, just push that value into the implementation.
2014-06-17 13:06:10 -04:00
void meta_window_actor_sync_updates_frozen (MetaWindowActor *self);
tests/stage-view: Added test for incorrect frame clock scheduling The test attempts to reproduce gnome-shell#4486, and is fixed by "window-actor/x11: Don't cache the frame-drawn frame clock". Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1947>
2021-07-30 05:44:24 -04:00
META_EXPORT_TEST
Fix corner cases where _NET_WM_FRAME_DRAWN might be missed The WM spec requires _NET_WM_FRAME_DRAWN to *always* be sent when there is an appropriate update to the sync counter value. We were potentially missing _NET_WM_FRAME_DRAWN when an application did a spontaneous update during an interactive resize and during effects. Refactor the code to always send _NET_WM_FRAME_DRAWN, even when a window is frozen. https://bugzilla.gnome.org/show_bug.cgi?id=693833
2013-02-14 13:40:55 -05:00
void meta_window_actor_queue_frame_drawn (MetaWindowActor *self,
gboolean no_delay_frame);
Remove Mutter namespace prefix Move all objects and functions namespaced with Mutter into the Meta namespace to get a single consistent namespace. Changes that aren't simply changing mutter to meta: MutterWindow => MetaWindowActor mutter_get_windows => meta_get_window_actors mutter_plugin_get_windows => meta_plugin_get_window_actors https://bugzilla.gnome.org/show_bug.cgi?id=628520
2010-10-18 13:27:14 -04:00
plugin-manager: Make the event an enum
2015-07-05 23:58:40 -04:00
void meta_window_actor_effect_completed (MetaWindowActor *actor,
MetaPluginEffect event);
Remove Mutter namespace prefix Move all objects and functions namespaced with Mutter into the Meta namespace to get a single consistent namespace. Changes that aren't simply changing mutter to meta: MutterWindow => MetaWindowActor mutter_get_windows => meta_get_window_actors mutter_plugin_get_windows => meta_plugin_get_window_actors https://bugzilla.gnome.org/show_bug.cgi?id=628520
2010-10-18 13:27:14 -04:00
Introduce MetaSurfaceActor for drawing MetaWindowActor content Instead of having MetaWindowActor only have one single MetaShapedTexture as actor drawing its content, introduce a new abstract MetaSurfaceActor that takes care of drawing. This is one step in the direction to decouple MetaWaylandSurface with a MetaWindow and MetaWindowActor (except for shell/xdg surfaces) in order to finally support subsurfaces like features, or any feature where window is not drawn using a single texture. The first step, implemented in this patch, is to not have MetaWindowActor work directly with a shaped texture. There are still some cases where it simply gets the texture and goes on as before, but this should be changed by either removing the need of going via MetaWindowActor or by adding some generic interface to MetaSurfaceActor that doesn't limit its functionality to one shaped texture. There should be no visible difference nor after this patch, but meta_window_actor_get_texture() and meta_surface_actor_get_texture() should be deprecated when equivalent functionality has been introduced. Signed-off-by: Jonas Ådahl <jadahl@gmail.com> https://bugzilla.gnome.org/show_bug.cgi?id=705502
2013-10-13 07:47:53 -04:00
MetaSurfaceActor *meta_window_actor_get_surface (MetaWindowActor *self);
window-actor: Make it clearer that the surface actor doesn't change The way code was structured made it easy to misunderstand things as the surface actor of a window actor could change over time. So is not the case, however, the intention of the corresponding "update" function was so that a surface actor could be assigned to a window actor as soon as the X11 window was associated with its corresponding wl_surface, if the window in question came from Xwayland. Restructure the code and internal API a bit to make it clear that a window actor only once gets a surface actor assigned to it, and that it after that point never changes. https://gitlab.gnome.org/GNOME/mutter/merge_requests/659
2019-06-27 13:33:24 -04:00
window-actor: Add API to get the surface actor candidate for scanout This replaces the API to get the topmost surface actor with an API to get the surface actor that could be a candidate for direct scanout. The advantage of this is that it allows X11 and Wayland specific restrictions for these actors. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2409>
2022-05-11 16:32:33 -04:00
MetaSurfaceActor *meta_window_actor_get_scanout_candidate (MetaWindowActor *self);
window-actor: Add API to get the topmost surface actor On Wayland a window actor may have more than one surface actor, most importantly when subsurfaces are used. Add a new function to request the one which is at the top - it will be used in the next commit. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2211>
2022-01-05 16:05:50 -05:00
window-actor: Make it clearer that the surface actor doesn't change The way code was structured made it easy to misunderstand things as the surface actor of a window actor could change over time. So is not the case, however, the intention of the corresponding "update" function was so that a surface actor could be assigned to a window actor as soon as the X11 window was associated with its corresponding wl_surface, if the window in question came from Xwayland. Restructure the code and internal API a bit to make it clear that a window actor only once gets a surface actor assigned to it, and that it after that point never changes. https://gitlab.gnome.org/GNOME/mutter/merge_requests/659
2019-06-27 13:33:24 -04:00
void meta_window_actor_assign_surface_actor (MetaWindowActor *self,
MetaSurfaceActor *surface_actor);
tests/stage-view: Added test for incorrect frame clock scheduling The test attempts to reproduce gnome-shell#4486, and is fixed by "window-actor/x11: Don't cache the frame-drawn frame clock". Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1947>
2021-07-30 05:44:24 -04:00
META_EXPORT_TEST
window-actor: add new signal "effects-completed" When using plugins, the effects will affect the MetaWindowActor size and position. Add a new signal "effects-completed" wired to the corresponding MetaWindowActor which is emitted when all effects are completed so that derived objects can be notified when all effects are completed and use the actual size and position. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/104
2018-04-04 04:10:32 -04:00
MetaWindowActor *meta_window_actor_from_window (MetaWindow *window);
tests/wayland-unit-tests: Add test case for remapping popup with subsurface This test reproduces the crash in https://gitlab.gnome.org/GNOME/mutter/-/issues/1828. It does not reproduce with 'window-actor/wayland: Remove subsurface actors on dispose' (dd416dd3e2eecfe1). applied. This test case differs slightly from the one that came with the dd416dd3e2eecfe1 as in that it uses withdrawn popup surfaces instead of explicitly client managed state. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1993>
2021-09-07 04:35:27 -04:00
META_EXPORT_TEST
window-actor: Add API to get a MetaWindowActor from a ClutterActor Make it so it returns the closest ancestry MetaWindowActor if it is a MetaSurfaceActor. We need this for Wayland subsurfaces, so we can support actions like Meta+Drag on them. https://gitlab.gnome.org/GNOME/mutter/merge_requests/604
2019-06-13 14:16:37 -04:00
MetaWindowActor *meta_window_actor_from_actor (ClutterActor *actor);
Introduce MetaSurfaceActor for drawing MetaWindowActor content Instead of having MetaWindowActor only have one single MetaShapedTexture as actor drawing its content, introduce a new abstract MetaSurfaceActor that takes care of drawing. This is one step in the direction to decouple MetaWaylandSurface with a MetaWindow and MetaWindowActor (except for shell/xdg surfaces) in order to finally support subsurfaces like features, or any feature where window is not drawn using a single texture. The first step, implemented in this patch, is to not have MetaWindowActor work directly with a shaped texture. There are still some cases where it simply gets the texture and goes on as before, but this should be changed by either removing the need of going via MetaWindowActor or by adding some generic interface to MetaSurfaceActor that doesn't limit its functionality to one shaped texture. There should be no visible difference nor after this patch, but meta_window_actor_get_texture() and meta_surface_actor_get_texture() should be deprecated when equivalent functionality has been introduced. Signed-off-by: Jonas Ådahl <jadahl@gmail.com> https://bugzilla.gnome.org/show_bug.cgi?id=705502
2013-10-13 07:47:53 -04:00
window-actor: Handle geometry scale Geometry scale is applied to each surface individually, using Clutter scales, and not only this breaks subsurfaces, it also pollutes the toolkit and makes the actor tree slightly too fragile. If GNOME Shell mistakenly tries to set the actor scale of any of these surfaces, for example, various artifacts might happen. Move geometry scale handling to MetaWindowActor. It is applied as a child transform operation, so that the Clutter-managed scale properties are left untouched. In the future where the entirety of the window is managed by a ClutterContent itself, the geometry scale will be applied directly into the transform matrix of MetaWindowActor. However, doing that now would break the various ClutterClones used by GNOME Shell, so the child transform is an acceptable compromise during this transition. https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
2019-07-12 13:33:17 -04:00
void meta_window_actor_set_geometry_scale (MetaWindowActor *window_actor,
int geometry_scale);
int meta_window_actor_get_geometry_scale (MetaWindowActor *window_actor);
window-actor: Add 'damaged' signal Make it possible to listen for damage on a window actor. For X11, the signal is emitted when damage is reported; for Wayland, it is emitted when any of the surfaces associated with the window is damaged. https://gitlab.gnome.org/GNOME/mutter/merge_requests/752
2019-08-26 09:09:53 -04:00
void meta_window_actor_notify_damaged (MetaWindowActor *window_actor);
window-actor: Move shapes, shadows and unredirection to X11 sub types Move out updating of various shapes (input, opaque, shape) indirectly from X11 to the corresponding X11 sub types of MetaWindowActor and MetaSurfaceActor. Also move fullscreen window unredirection code with it. We want to effectively do something similar for MetaCompositorServer, but it will work differently enough not to share too much logic. While it would have been nice to move things piece by piece, things were too intertwined to make it feasible. This has the side effect fixing accidentally and arbitrarily adding server side shadow to Wayland surfaces. Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/727 https://gitlab.gnome.org/GNOME/mutter/merge_requests/734
2019-08-17 04:00:46 -04:00
gboolean meta_window_actor_is_frozen (MetaWindowActor *self);
gboolean meta_window_actor_is_opaque (MetaWindowActor *self);
window-actor: Add API to update regions For X11 clients running on Xwayland, the opaque, input and shape regions are processed from different properties and may occur at a different time, before the actual buffer is eventually committed by Xwayland. Add a new API `update_regions` to window actor to trigger the update of those regions when needed. https://gitlab.gnome.org/GNOME/mutter/merge_requests/1091
2020-03-03 04:26:54 -05:00
void meta_window_actor_update_regions (MetaWindowActor *self);
window-actor: Add a new can_freeze_commits() API Mutter freezes Xwayland commits when resizing windows, and thaw them in the window actors' after_paint() for X11. Yet, after_paint() could be never called, as when a new window is mapped while the overview is active in gnome-shell. As a result, the content of the X11 window will remain invisible to the overview. Add a new window actor API to tell whether commits can be frozen. For Wayland window actors, this always return FALSE, whereas for X11 window actors, it checks whether the Clutter actor is mapped. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1678>
2021-01-22 10:26:17 -05:00
gboolean meta_window_actor_can_freeze_commits (MetaWindowActor *self);
Remove Mutter namespace prefix Move all objects and functions namespaced with Mutter into the Meta namespace to get a single consistent namespace. Changes that aren't simply changing mutter to meta: MutterWindow => MetaWindowActor mutter_get_windows => meta_get_window_actors mutter_plugin_get_windows => meta_plugin_get_window_actors https://bugzilla.gnome.org/show_bug.cgi?id=628520
2010-10-18 13:27:14 -04:00
#endif /* META_WINDOW_ACTOR_PRIVATE_H */
Reference in New Issue Copy Permalink