isa/mutter
1
0
Fork 0
mirror of https://github.com/brl/mutter.git synced 2024-11-29 03:20:46 -05:00
Code Issues Packages Projects Releases Wiki Activity
c7f989c1e2
mutter/src/compositor/compositor-private.h

100 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 18:56:15 -04: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 15:33:20 -04: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 10:53:14 -04: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 04:36:24 -04:00
#include "clutter/clutter.h"
#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 18:56:15 -04: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 13:04:41 -04: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 09:11:53 -04: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 03:32:33 -05: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 13:04:41 -04: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 17:25:54 -04: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 03:27:33 -05: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 17:25:54 -04:00
void (* unmanage) (MetaCompositor *compositor);
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) (MetaCompositor *compositor,
ClutterStageView *stage_view);
void (* after_paint) (MetaCompositor *compositor,
ClutterStageView *stage_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 17:25:54 -04: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 10:53:14 -04:00
int64_t (* monotonic_to_high_res_xserver_time) (MetaCompositor *compositor,
int64_t time_us);
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 15:33:20 -04: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 03:27:33 -05: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 13:04:41 -04: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 14:11:08 -05:00
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 17:31:22 -04: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 13:27:14 -04:00
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 17:31:22 -04:00
gboolean meta_begin_modal_for_plugin (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 13:27:14 -04:00
MetaPlugin *plugin,
MetaModalOptions options,
guint32 timestamp);
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 17:31:22 -04:00
void meta_end_modal_for_plugin (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 13:27:14 -04:00
MetaPlugin *plugin,
guint32 timestamp);
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 13:04:41 -04: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 10:53:14 -04: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 14:09:38 -05: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-07 23:10:21 -05: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 13:48:52 -05: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 05:20:54 -04: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 05:07:22 -05: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 15:04:56 -04: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 17:25:54 -04: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 13:04:41 -04:00
MetaDisplay * meta_compositor_get_display (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 17:25:54 -04: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 13:04:41 -04:00
ClutterStage * meta_compositor_get_stage (MetaCompositor *compositor);
gboolean meta_compositor_is_switching_workspace (MetaCompositor *compositor);
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 03:32:33 -05:00
MetaLaters * meta_compositor_get_laters (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 10:53:14 -04: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 18:56:15 -04:00
#endif /* META_COMPOSITOR_PRIVATE_H */
Reference in New Issue Copy Permalink