sungmg/mutter-performance-source
1
0
Fork 0
Code Activity
mutter-performance-source/src/compositor/compositor-private.h

103 lines
3.7 KiB
C
Raw Normal View History

Split shadow code into a separate file Separate code related to creating the gaussian-blurred shadow texture into a separate file. Move the definition of MetaCompositor into a compositor-private.h so that the shadow code can cache the source in the compositor structure. http://bugzilla.gnome.org/show_bug.cgi?id=587251
2009-06-25 22:56:15 +00:00
/* -*- mode: C; c-file-style: "gnu"; indent-tabs-mode: nil; -*- */
#ifndef META_COMPOSITOR_PRIVATE_H
#define META_COMPOSITOR_PRIVATE_H
Separate source and header files for MutterWindow compositor.c: Move MutterWindow code to mutter-window.c; rename map_win() to mutter_window_map(), etc. mutter-window-private.h: New private header file for MutterWindow functions used internally to the compositor. compositor-mutter.h: Move MutterWindow declarations to mutter-window.h; move a couple of private functions to compositor-private.h compositor-private.h: Move MetaCompScreen declaration to here: Conceptually it's private to compositor.c, but MutterWindow manipulates some of the lists directly for now. mutter-plugin.c compositor.c: Don't call mutter_window_effect_completed() for MUTTER_PLUGIN_SWITCH_WORKSPACE, but use a new mutter_switch_workspace_completed(), since the window is just used to identify a screen. http://bugzilla.gnome.org/show_bug.cgi?id=587251
2009-06-26 19:33:20 +00:00
#include <X11/extensions/Xfixes.h>
compositor: Make sure _NET_WM_FRAME_DRAWN timestamp has the right scope The timestamp sent with _NET_WM_FRAME_DRAWN should be in "high resolution X server timestamps", meaning they should have the same scope as the built in X11 32 bit unsigned integer timestamps, i.e. overflow at the same time. This was not done correctly when mutter had determined the X server used the monotonic clock, where it'd just forward the monotonic clock, confusing any client using _NET_WM_FRAME_DRAWN and friends. Fix this by 1) splitting the timestamp conversiot into an X11 case and a display server case, where the display server case simply clamps the monotonic clock, as it is assumed Xwayland is always usign the monotonic clock, and 2) if we're a X11 compositing manager, if the X server is using the monotonic clock, apply the same semantics as the display server case and always just clamp, or if not, calculate the offset every 10 seconds, and offset the monotonic clock timestamp with the calculated X server timestamp offset. This fixes an issue that would occur if mutter (or rather GNOME Shell) would have been started before a X11 timestamp overflow, after the overflow happened. In this case, GTK3 clients would get unclamped timestamps, and get very confused, resulting in frames queued several weeks into the future. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1494
2020-07-08 14:53:14 +00:00
#include "clutter/clutter-mutter.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 "clutter/clutter.h"
compositor: Expose the MetaCompositorView in before_paint () vfunc The idea is that the state of the MetaCompositorView shall be up-to-date only in specific scenarios, thus allowing operations performed on it to be queued and aggregated to be handled in the right time, and only if they are still necessary. For example, in a following commit, the top window actor in each view will be planned (if needed) only once before painting a frame, rendering the top window actor in the MetaCompositorView potentially stale in all other times. Similarly, if a MetaCompositorView is destroyed before the beginning of the frame, a queued operation to update its top window actor can be discarded. As an interface segragation measure, and as part of an attempt to avoid the use of g_return_if_fail () to check the validity of the MetaCompositorView's state in multiple places (which is still prone to human error), the interfaces through which a MetaCompositorView is made available would only ones where it's state is gurenteed to be up-to-date. Specifically, this commit gurentees that the state of the MetaCompositorView would be up-to-date during the before_paint () and after_paint () vfuncs exposed to child classes of the MetaCompositor. The frame_in_progress variable will be used in a following commit to guarantee that the MetaCompositorView's state is not invalidated during this time. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2526>
2022-07-11 09:23:24 +00:00
#include "compositor/meta-compositor-view.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-plugin-manager.h"
#include "compositor/meta-window-actor-private.h"
#include "meta/compositor.h"
#include "meta/display.h"
Split shadow code into a separate file Separate code related to creating the gaussian-blurred shadow texture into a separate file. Move the definition of MetaCompositor into a compositor-private.h so that the shadow code can cache the source in the compositor structure. http://bugzilla.gnome.org/show_bug.cgi?id=587251
2009-06-25 22:56:15 +00:00
compositor: Make type derivable This is so that we can split it up properly into X11 compositor and display server compositor sub types. https://gitlab.gnome.org/GNOME/mutter/merge_requests/727
2019-08-14 17:04:41 +00:00
/* Wait 2ms after vblank before starting to draw next frame */
#define META_SYNC_DELAY 2
compositor: Sync X drawing only once per frame We only need to call XSync() once per frame to synchronize X with GL drawing. https://bugzilla.gnome.org/show_bug.cgi?id=728464
2014-05-12 13:11:53 +00:00
later: Make MetaCompositor the owner of the MetaLaters state Since the order of destruction during MetaDisplay tear down is a bit unordered, there are pieces that try to destruct its compositing dependent pieces (i.e. queued MetaLater callbacks) after MetaCompositor has been cleaned up, meaning we need to put some slightly awkward NULL checks to avoid crashing. https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
2020-03-03 08:32:33 +00:00
typedef struct _MetaLaters MetaLaters;
compositor: Make type derivable This is so that we can split it up properly into X11 compositor and display server compositor sub types. https://gitlab.gnome.org/GNOME/mutter/merge_requests/727
2019-08-14 17:04:41 +00:00
struct _MetaCompositorClass
{
GObjectClass parent_class;
compositor: Move out X11 compositing code into sub type Introduce MetaCompositorX11, dealing with being a X11 compositor, and MetaCompositorServer, being a compositor while also being the display server itself, e.g. a Wayland display server. https://gitlab.gnome.org/GNOME/mutter/merge_requests/727
2019-08-14 21:25:54 +00:00
display: Initialize MetaCompositor in two steps MetaCompositor is the place in mutter that manages the higher level state of compositing, such as handling what happens before and after paint. In order for other units that depend on having a compositor instance active, but should be initialized before the X11 implementation of MetaCompositor registers as a X11 compositing manager, split the initialization of compositing into two steps: 1) Instantiate the object - only construct the instance, making it possible for users to start listening to signals etc 2) Manage - this e.g. establishes the compositor as the X11 compositing manager and similar things. This will enable us to put compositing dependent scattered global variables into a MetaCompositor owned object. For now, compositor management is internally done by calling a new `meta_compositor_do_manage()`, as right now we can't change the API of `meta_compositor_manage()` as it is public. For the next version, manual management of compositing will removed from the public API, and only managed internally. https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
2020-03-03 08:27:33 +00:00
gboolean (* manage) (MetaCompositor *compositor,
GError **error);
compositor: Move out X11 compositing code into sub type Introduce MetaCompositorX11, dealing with being a X11 compositor, and MetaCompositorServer, being a compositor while also being the display server itself, e.g. a Wayland display server. https://gitlab.gnome.org/GNOME/mutter/merge_requests/727
2019-08-14 21:25:54 +00:00
void (* unmanage) (MetaCompositor *compositor);
compositor: Expose the MetaCompositorView in before_paint () vfunc The idea is that the state of the MetaCompositorView shall be up-to-date only in specific scenarios, thus allowing operations performed on it to be queued and aggregated to be handled in the right time, and only if they are still necessary. For example, in a following commit, the top window actor in each view will be planned (if needed) only once before painting a frame, rendering the top window actor in the MetaCompositorView potentially stale in all other times. Similarly, if a MetaCompositorView is destroyed before the beginning of the frame, a queued operation to update its top window actor can be discarded. As an interface segragation measure, and as part of an attempt to avoid the use of g_return_if_fail () to check the validity of the MetaCompositorView's state in multiple places (which is still prone to human error), the interfaces through which a MetaCompositorView is made available would only ones where it's state is gurenteed to be up-to-date. Specifically, this commit gurentees that the state of the MetaCompositorView would be up-to-date during the before_paint () and after_paint () vfuncs exposed to child classes of the MetaCompositor. The frame_in_progress variable will be used in a following commit to guarantee that the MetaCompositorView's state is not invalidated during this time. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2526>
2022-07-11 09:23:24 +00:00
void (* before_paint) (MetaCompositor *compositor,
MetaCompositorView *compositor_view);
void (* after_paint) (MetaCompositor *compositor,
MetaCompositorView *compositor_view);
compositor: Move out X11 compositing code into sub type Introduce MetaCompositorX11, dealing with being a X11 compositor, and MetaCompositorServer, being a compositor while also being the display server itself, e.g. a Wayland display server. https://gitlab.gnome.org/GNOME/mutter/merge_requests/727
2019-08-14 21:25:54 +00:00
void (* remove_window) (MetaCompositor *compositor,
MetaWindow *window);
compositor: Make sure _NET_WM_FRAME_DRAWN timestamp has the right scope The timestamp sent with _NET_WM_FRAME_DRAWN should be in "high resolution X server timestamps", meaning they should have the same scope as the built in X11 32 bit unsigned integer timestamps, i.e. overflow at the same time. This was not done correctly when mutter had determined the X server used the monotonic clock, where it'd just forward the monotonic clock, confusing any client using _NET_WM_FRAME_DRAWN and friends. Fix this by 1) splitting the timestamp conversiot into an X11 case and a display server case, where the display server case simply clamps the monotonic clock, as it is assumed Xwayland is always usign the monotonic clock, and 2) if we're a X11 compositing manager, if the X server is using the monotonic clock, apply the same semantics as the display server case and always just clamp, or if not, calculate the offset every 10 seconds, and offset the monotonic clock timestamp with the calculated X server timestamp offset. This fixes an issue that would occur if mutter (or rather GNOME Shell) would have been started before a X11 timestamp overflow, after the overflow happened. In this case, GTK3 clients would get unclamped timestamps, and get very confused, resulting in frames queued several weeks into the future. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1494
2020-07-08 14:53:14 +00:00
int64_t (* monotonic_to_high_res_xserver_time) (MetaCompositor *compositor,
int64_t time_us);
compositor: Refactor backend-specific code into MetaCompositor vfuncs Do these Wayland operations (that apply on both native and nested backends) in the MetaCompositorServer subclass. We want to add more backend specific behavior here in the future. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1659>
2021-02-13 11:48:31 +00:00
void (* grab_begin) (MetaCompositor *compositor);
void (* grab_end) (MetaCompositor *compositor);
compositor: Introduce MetaCompositorViewNative This class is meant to hold logic specific to the native backend in the context of a MetaCompositorView. Its addition requires making MetaCompositorView inheritable, and an addition of a virtual function which allows each compositor to create its own MetaCompositorView instance. In the case of the MetaCompositorNative, a MetaCompositorViewNative is created. In all other cases, a MetaCompositorView is created. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2526>
2022-07-15 09:06:12 +00:00
MetaCompositorView * (* create_view) (MetaCompositor *compositor,
ClutterStageView *stage_view);
Separate source and header files for MutterWindow compositor.c: Move MutterWindow code to mutter-window.c; rename map_win() to mutter_window_map(), etc. mutter-window-private.h: New private header file for MutterWindow functions used internally to the compositor. compositor-mutter.h: Move MutterWindow declarations to mutter-window.h; move a couple of private functions to compositor-private.h compositor-private.h: Move MetaCompScreen declaration to here: Conceptually it's private to compositor.c, but MutterWindow manipulates some of the lists directly for now. mutter-plugin.c compositor.c: Don't call mutter_window_effect_completed() for MUTTER_PLUGIN_SWITCH_WORKSPACE, but use a new mutter_switch_workspace_completed(), since the window is just used to identify a screen. http://bugzilla.gnome.org/show_bug.cgi?id=587251
2009-06-26 19:33:20 +00:00
};
display: Initialize MetaCompositor in two steps MetaCompositor is the place in mutter that manages the higher level state of compositing, such as handling what happens before and after paint. In order for other units that depend on having a compositor instance active, but should be initialized before the X11 implementation of MetaCompositor registers as a X11 compositing manager, split the initialization of compositing into two steps: 1) Instantiate the object - only construct the instance, making it possible for users to start listening to signals etc 2) Manage - this e.g. establishes the compositor as the X11 compositing manager and similar things. This will enable us to put compositing dependent scattered global variables into a MetaCompositor owned object. For now, compositor management is internally done by calling a new `meta_compositor_do_manage()`, as right now we can't change the API of `meta_compositor_manage()` as it is public. For the next version, manual management of compositing will removed from the public API, and only managed internally. https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
2020-03-03 08:27:33 +00:00
gboolean meta_compositor_do_manage (MetaCompositor *compositor,
GError **error);
compositor: Make type derivable This is so that we can split it up properly into X11 compositor and display server compositor sub types. https://gitlab.gnome.org/GNOME/mutter/merge_requests/727
2019-08-14 17:04:41 +00:00
void meta_compositor_remove_window_actor (MetaCompositor *compositor,
MetaWindowActor *window_actor);
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 19:11:08 +00:00
compositor: Keep track of the top window actor on each view First, add logic in MetaCompositorView to find topmost visible MetaWindowActor on its view, and expose it through a new API. Then, queue an update to find the top MetaWindowActor of each MetaCompositorView in the following cases: 1. The MetaCompositor is in its initial state. 2. The window stack order has changed. 3. A window has changed its visibility. 4. A "stage-views-changed" signal was emitted for a MetaWindowActor. Finally, perform the queued update in meta_compositor_before_paint (), and assert that an update isn't queued during painting. This ensures that the top window actor in the MetaCompositorView remains up-to-date and available to child classes of MetaCompositor throughout the entire paint stage. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2526>
2022-07-02 19:51:13 +00:00
void meta_compositor_window_actor_stage_views_changed (MetaCompositor *compositor);
compositor: Kill off MetaCompScreen Compositors haven't been able to manage more than one screen for quite a while. Merge MetaCompScreen into MetaCompositor, and update the API to match. We still keep MetaScreen in the public compositor API for compatibility purposes.
2014-03-18 21:31:22 +00:00
void meta_switch_workspace_completed (MetaCompositor *compositor);
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 17:27:14 +00:00
compositor: Make type derivable This is so that we can split it up properly into X11 compositor and display server compositor sub types. https://gitlab.gnome.org/GNOME/mutter/merge_requests/727
2019-08-14 17:04:41 +00:00
MetaPluginManager * meta_compositor_get_plugin_manager (MetaCompositor *compositor);
compositor: Make sure _NET_WM_FRAME_DRAWN timestamp has the right scope The timestamp sent with _NET_WM_FRAME_DRAWN should be in "high resolution X server timestamps", meaning they should have the same scope as the built in X11 32 bit unsigned integer timestamps, i.e. overflow at the same time. This was not done correctly when mutter had determined the X server used the monotonic clock, where it'd just forward the monotonic clock, confusing any client using _NET_WM_FRAME_DRAWN and friends. Fix this by 1) splitting the timestamp conversiot into an X11 case and a display server case, where the display server case simply clamps the monotonic clock, as it is assumed Xwayland is always usign the monotonic clock, and 2) if we're a X11 compositing manager, if the X server is using the monotonic clock, apply the same semantics as the display server case and always just clamp, or if not, calculate the offset every 10 seconds, and offset the monotonic clock timestamp with the calculated X server timestamp offset. This fixes an issue that would occur if mutter (or rather GNOME Shell) would have been started before a X11 timestamp overflow, after the overflow happened. In this case, GTK3 clients would get unclamped timestamps, and get very confused, resulting in frames queued several weeks into the future. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1494
2020-07-08 14:53:14 +00:00
int64_t meta_compositor_monotonic_to_high_res_xserver_time (MetaCompositor *compositor,
int64_t monotonic_time_us);
Add meta_compositor_monotonic_time_to_server_time() Add a function to convert from g_get_monotonic_time() to a "high-resolution server timestamp" with microsecond precision. These timestamps will be used when communicating frame timing information to the client. https://bugzilla.gnome.org/show_bug.cgi?id=685463
2012-11-12 19:09:38 +00:00
bell: Flash whole window if the window had no frame CSD X11 clients and Wayland clients don't have a window frame drawn by the compositor to flash. So instead of flashing the whole screen when configured to just flash the window, flash just the window region. https://bugzilla.gnome.org/show_bug.cgi?id=763284
2016-03-08 04:10:21 +00:00
void meta_compositor_flash_window (MetaCompositor *compositor,
MetaWindow *window);
compositor: Expose MetaPlugin vmethod to create a MetaCloseDialog So the actual close dialog can be overridden by MetaPlugin implementations. https://bugzilla.gnome.org/show_bug.cgi?id=711619
2017-01-26 18:48:52 +00:00
MetaCloseDialog * meta_compositor_create_close_dialog (MetaCompositor *compositor,
MetaWindow *window);
compositor: add vmethod to override inhibit shortcut dialog A MetaPlugin implementation of the MetaInhibitShortcutsDialog can be used in place of the default inhibit shortcut. https://bugzilla.gnome.org/show_bug.cgi?id=783342
2017-06-14 09:20:54 +00:00
MetaInhibitShortcutsDialog * meta_compositor_create_inhibit_shortcuts_dialog (MetaCompositor *compositor,
MetaWindow *window);
compositor: Add "locate_pointer" vmethod This method is invoked to locate the pointer on screen. https://gitlab.gnome.org/GNOME/mutter/merge_requests/453 https://gitlab.gnome.org/GNOME/gnome-shell/issues/981 https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/merge_requests/19 https://gitlab.gnome.org/GNOME/gnome-settings-daemon/merge_requests/86
2019-02-20 10:07:22 +00:00
void meta_compositor_locate_pointer (MetaCompositor *compositor);
compositor: Add explicit API call to redirect X11 windows This is not useful yet, but will be when Xwayland may restart https://gitlab.gnome.org/GNOME/mutter/merge_requests/709
2019-05-24 19:04:56 +00:00
void meta_compositor_redirect_x11_windows (MetaCompositor *compositor);
compositor: Move out X11 compositing code into sub type Introduce MetaCompositorX11, dealing with being a X11 compositor, and MetaCompositorServer, being a compositor while also being the display server itself, e.g. a Wayland display server. https://gitlab.gnome.org/GNOME/mutter/merge_requests/727
2019-08-14 21:25:54 +00:00
gboolean meta_compositor_is_unredirect_inhibited (MetaCompositor *compositor);
compositor: Make type derivable This is so that we can split it up properly into X11 compositor and display server compositor sub types. https://gitlab.gnome.org/GNOME/mutter/merge_requests/727
2019-08-14 17:04:41 +00:00
MetaDisplay * meta_compositor_get_display (MetaCompositor *compositor);
backends/x11: Update MetaBackend on ClutterEvent processing This should fix wonky handling of last used device and pointer visibility on X11. At least does on --nested under presence of touchscreen/tablet. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/285>
2022-02-05 12:12:48 +00:00
MetaBackend * meta_compositor_get_backend (MetaCompositor *compositor);
compositor: Move out X11 compositing code into sub type Introduce MetaCompositorX11, dealing with being a X11 compositor, and MetaCompositorServer, being a compositor while also being the display server itself, e.g. a Wayland display server. https://gitlab.gnome.org/GNOME/mutter/merge_requests/727
2019-08-14 21:25:54 +00:00
MetaWindowActor * meta_compositor_get_top_window_actor (MetaCompositor *compositor);
compositor: Make type derivable This is so that we can split it up properly into X11 compositor and display server compositor sub types. https://gitlab.gnome.org/GNOME/mutter/merge_requests/727
2019-08-14 17:04:41 +00:00
ClutterStage * meta_compositor_get_stage (MetaCompositor *compositor);
gboolean meta_compositor_is_switching_workspace (MetaCompositor *compositor);
core: Handle redirection changes in and out of ClutterGrab grabs Wayland event processing and WM operations are themselves outside the ClutterGrab loop so far. Until this is sorted out, these pieces of event handling have got to learn to stay aside while there is a ClutterGrab going on. So, synchronize foci and other state when grabs come in or out, and make it sure that Wayland event processing does not happen while grabs happen. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2099>
2021-11-17 22:31:11 +00:00
void meta_compositor_grab_begin (MetaCompositor *compositor);
void meta_compositor_grab_end (MetaCompositor *compositor);
compositor: Make sure _NET_WM_FRAME_DRAWN timestamp has the right scope The timestamp sent with _NET_WM_FRAME_DRAWN should be in "high resolution X server timestamps", meaning they should have the same scope as the built in X11 32 bit unsigned integer timestamps, i.e. overflow at the same time. This was not done correctly when mutter had determined the X server used the monotonic clock, where it'd just forward the monotonic clock, confusing any client using _NET_WM_FRAME_DRAWN and friends. Fix this by 1) splitting the timestamp conversiot into an X11 case and a display server case, where the display server case simply clamps the monotonic clock, as it is assumed Xwayland is always usign the monotonic clock, and 2) if we're a X11 compositing manager, if the X server is using the monotonic clock, apply the same semantics as the display server case and always just clamp, or if not, calculate the offset every 10 seconds, and offset the monotonic clock timestamp with the calculated X server timestamp offset. This fixes an issue that would occur if mutter (or rather GNOME Shell) would have been started before a X11 timestamp overflow, after the overflow happened. In this case, GTK3 clients would get unclamped timestamps, and get very confused, resulting in frames queued several weeks into the future. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1494
2020-07-08 14:53:14 +00:00
/*
* This function takes a 64 bit time stamp from the monotonic clock, and clamps
* it to the scope of the X server clock, without losing the granularity.
*/
static inline int64_t
meta_translate_to_high_res_xserver_time (int64_t time_us)
{
int64_t us;
int64_t ms;
us = time_us % 1000;
ms = time_us / 1000;
return ms2us (ms & 0xffffffff) + us;
}
Split shadow code into a separate file Separate code related to creating the gaussian-blurred shadow texture into a separate file. Move the definition of MetaCompositor into a compositor-private.h so that the shadow code can cache the source in the compositor structure. http://bugzilla.gnome.org/show_bug.cgi?id=587251
2009-06-25 22:56:15 +00:00
#endif /* META_COMPOSITOR_PRIVATE_H */
Copy permalink