sungmg/mutter-performance-source
1
0
Fork 0
Code Activity
mutter-performance-source/src/core/stack-tracker.c

1263 lines
36 KiB
C
Raw Normal View History

Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
/* -*- mode: C; c-file-style: "gnu"; indent-tabs-mode: nil; -*- */
Fix gobs of gtk-doc warnings https://bugzilla.gnome.org/show_bug.cgi?id=676856
2013-02-15 18:42:08 +00:00
/*
* SECTION:stack-tracker
* @short_description: Track stacking order for compositor
*
* #MetaStackTracker maintains the most accurate view we have at a
* given point of time of the ordering of the children of the root
* window (including override-redirect windows.) This is used to order
* the windows when the compositor draws them.
*
* By contrast, #MetaStack is responsible for keeping track of how we
* think that windows *should* be ordered. For windows we manage
* (non-override-redirect windows), the two stacking orders will be
* the same.
*/
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
/*
* Copyright (C) 2009 Red Hat, Inc.
*
* 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
Changed obsolete FSF postal address into generic URL. Fix https://bugzilla.gnome.org/show_bug.cgi?id=721517 #2
2014-01-12 01:42:06 +00:00
* along with this program; if not, see <http://www.gnu.org/licenses/>.
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
*/
Clean up include macros mess The order and way include macros were structured was chaotic, with no real common thread between files. Try to tidy up the mess with some common scheme, to make things look less messy.
2018-07-10 08:36:24 +00:00
#include "config.h"
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
Clean up include macros mess The order and way include macros were structured was chaotic, with no real common thread between files. Try to tidy up the mess with some common scheme, to make things look less messy.
2018-07-10 08:36:24 +00:00
#include "core/stack-tracker.h"
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
Clean up include macros mess The order and way include macros were structured was chaotic, with no real common thread between files. Try to tidy up the mess with some common scheme, to make things look less messy.
2018-07-10 08:36:24 +00:00
#include <string.h>
Move compositor-stack handling to MetaStackTracker In order to properly track the stacking order for override-redirect windows, move meta_compositor_sync_stack() call into MetaStackTracker. In the new location, we sync the stack as a before-redraw idle function, rather then using the freeze-thaw facilities of MetaStack. This is simpler, and also properly compresses multiple stack changes on notifications received from the X server. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-14 12:04:28 +00:00
Clean up include macros mess The order and way include macros were structured was chaotic, with no real common thread between files. Try to tidy up the mess with some common scheme, to make things look less messy.
2018-07-10 08:36:24 +00:00
#include "core/display-private.h"
#include "core/frame.h"
#include "meta/compositor.h"
#include "meta/meta-x11-errors.h"
#include "meta/util.h"
Start populating MetaX11Display - Moved xdisplay, name and various atoms from MetaDisplay - Moved xroot, screen_name, default_depth and default_xvisual from MetaScreen - Moved some X11 specific functions from screen.c and display.c to meta-x11-display.c https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 16:26:30 +00:00
#include "x11/meta-x11-display-private.h"
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
/* The complexity here comes from resolving two competing factors:
*
* - We need to have a view of the stacking order that takes into
* account everything we have done without waiting for events
* back from the X server; we don't want to draw intermediate
* partially-stacked stack states just because we haven't received
* some notification yet.
*
* - Only the X server has an accurate view of the complete stacking;
* when we make a request to restack windows, we don't know how
* it will affect override-redirect windows, because at any point
* applications may restack these windows without our involvement.
*
* The technique we use is that we keep three sets of information:
*
* - The stacking order on the server as known from the last
* event we received.
* - A queue of stacking requests that *we* made subsequent to
* that last event.
* - A predicted stacking order, derived from applying the queued
* requests to the last state from the server.
*
* When we receive a new event: a) we compare the serial in the event to
* the serial of the queued requests and remove any that are now
MetaStackTracker: Avoid queueing resync for obvious no-ops Since we can't distinguish a ConfigureEvent that indicates a raise from a ConfigureEvent that indicates a move, we get lots of STACK_OP_RAISE_ABOVE events for windows that are already in the right place in the stacking order. Avoid queueing a restack in that case. https://bugzilla.gnome.org/show_bug.cgi?id=634771
2010-11-13 19:07:07 +00:00
* no longer pending b) if necessary, drop the predicted stacking
* order to recompute it at the next opportunity.
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
*
* Possible optimizations:
* Keep the stacks as an array + reverse-mapping hash table to avoid
* linear lookups.
* Keep the stacks as a GList + reverse-mapping hash table to avoid
* linear lookups and to make restacking constant-time.
*/
typedef union _MetaStackOp MetaStackOp;
Use a consistent style for enum braces https://gitlab.gnome.org/GNOME/mutter/merge_requests/361
2018-12-19 08:04:25 +00:00
typedef enum
{
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
STACK_OP_ADD,
STACK_OP_REMOVE,
STACK_OP_RAISE_ABOVE,
STACK_OP_LOWER_BELOW
} MetaStackOpType;
Use a consistent style for enum braces https://gitlab.gnome.org/GNOME/mutter/merge_requests/361
2018-12-19 08:04:25 +00:00
typedef enum
{
MetaStackTracker: eliminate the resynchronization process The step where we requery the stacking order from the server than combine it in an arbitrary fashion with Wayland windows can be eliminated by observing that we are the final authority for Wayland window stacking - so if we apply each X event that we receive from the X server to our stack in a way that leaves the X windows ordered in the same way as on the server, and apply events that we have stored locally in a way that doesn't affect the ordering of X windows, than we have a fully correct ordering of windows. Ordering this in the order of first applying the X event and then applying the local portion also means that as long as we had an up-to-date view of the X stack the composite operation will be identical to what was requested. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 17:41:27 +00:00
APPLY_DEFAULT = 0,
/* Only do restacking that we can do locally without changing
* the order of X windows. After we've received any stack
* events from the X server, we apply the locally cached
* ops in this mode to handle the non-X parts */
NO_RESTACK_X_WINDOWS = 1 << 0,
/* If the stacking operation wouldn't change the order of X
* windows, ignore it. We use this when applying events received
* from X so that a spontaneous ConfigureNotify (for a move, say)
* doesn't change the stacking of X windows with respect to
* Wayland windows. */
IGNORE_NOOP_X_RESTACK = 1 << 1
} ApplyFlags;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
/* MetaStackOp represents a "stacking operation" - a change to
* apply to a window stack. Depending on the context, it could
* either reflect a request we have sent to the server, or a
* notification event we received from the X server.
*/
union _MetaStackOp
{
struct {
MetaStackOpType type;
gulong serial;
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
guint64 window;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
} any;
struct {
MetaStackOpType type;
gulong serial;
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
guint64 window;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
} add;
struct {
MetaStackOpType type;
gulong serial;
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
guint64 window;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
} remove;
struct {
MetaStackOpType type;
gulong serial;
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
guint64 window;
guint64 sibling;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
} raise_above;
struct {
MetaStackOpType type;
gulong serial;
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
guint64 window;
guint64 sibling;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
} lower_below;
};
struct _MetaStackTracker
{
Move stack tracking and guard_window outside of MetaScreen Move stack, stack_tracker to MetaDisplay guard_window to MetaX11Display https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 17:03:51 +00:00
MetaDisplay *display;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
/* This is the serial of the last request we made that was reflected
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
* in xserver_stack
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
*/
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
gulong xserver_serial;
/* A combined stack containing X and Wayland windows but without
* any unverified operations applied. */
GArray *verified_stack;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
/* This is a queue of requests we've made to change the stacking order,
* where we haven't yet gotten a reply back from the server.
*/
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
GQueue *unverified_predictions;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
/* This is how we think the stack is, based on verified_stack, and
* on the unverified_predictions we've made subsequent to
* verified_stack.
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
*/
GArray *predicted_stack;
Move compositor-stack handling to MetaStackTracker In order to properly track the stacking order for override-redirect windows, move meta_compositor_sync_stack() call into MetaStackTracker. In the new location, we sync the stack as a before-redraw idle function, rather then using the freeze-thaw facilities of MetaStack. This is simpler, and also properly compresses multiple stack changes on notifications received from the X server. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-14 12:04:28 +00:00
/* Idle function used to sync the compositor's view of the window
* stack up with our best guess before a frame is drawn.
*/
Use "later functions" to fix priority problems with Clutter redraw There was a problem where if, for example, a restack was triggered out of a clutter event handler, then after Clutter processed the events, it would proceed immmediately on to repaint the stage without ever returning control to the GLib main loop. So even though we had an idle handler installed with a higher priority than the Clutter stage repainting the clutter stage repainting would happen first and we'd get a wrong frame. Fix this by introducing the idea of "later functions", which abstract the idea of "doing something later" away from g_idle_add() and use a combination of GLib idle functions and Clutter "repaint functions" to get our callbacks triggered at the right time, even when they are installed from a clutter event handler. https://bugzilla.gnome.org/show_bug.cgi?id=596334 This also resolve a FIXME where MUTTER_PRIORITY_BEFORE_REDRAW could starve stage repainting.
2009-09-25 19:47:22 +00:00
guint sync_stack_later;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
};
stack-tracker: Keep override redirect windows on top Since commit 6b5cf2e, we keep override redirect windows on a layer above regular windows in the clutter actor scene graph. In the X server, and thus for input purposes, these windows might end up being stacked below regular windows though, e.g. because a new regular window is mapped after an OR window. Fix this disconnect by re-stacking OR windows on top when syncing the window stack with the compositor. https://bugzilla.gnome.org/show_bug.cgi?id=780485
2017-05-19 15:11:19 +00:00
static void
meta_stack_tracker_keep_override_redirect_on_top (MetaStackTracker *tracker);
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
static inline const char *
get_window_desc (MetaStackTracker *tracker,
guint64 window)
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
{
Move stack tracking and guard_window outside of MetaScreen Move stack, stack_tracker to MetaDisplay guard_window to MetaX11Display https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 17:03:51 +00:00
return meta_display_describe_stack_id (tracker->display, window);
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
}
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
static void
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
meta_stack_op_dump (MetaStackTracker *tracker,
MetaStackOp *op,
const char *prefix,
const char *suffix)
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
{
Fix warnings when building without verbose mode
2018-07-12 15:08:52 +00:00
#ifdef WITH_VERBOSE_MODE
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
const char *window_desc = get_window_desc (tracker, op->any.window);
Fix warnings when building without verbose mode
2018-07-12 15:08:52 +00:00
#endif
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
switch (op->any.type)
{
case STACK_OP_ADD:
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
meta_topic (META_DEBUG_STACK, "%sADD(%s; %ld)%s",
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
prefix, window_desc, op->any.serial, suffix);
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
break;
case STACK_OP_REMOVE:
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
meta_topic (META_DEBUG_STACK, "%sREMOVE(%s; %ld)%s",
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
prefix, window_desc, op->any.serial, suffix);
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
break;
case STACK_OP_RAISE_ABOVE:
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
{
meta_topic (META_DEBUG_STACK, "%sRAISE_ABOVE(%s, %s; %ld)%s",
prefix,
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
window_desc,
get_window_desc (tracker, op->raise_above.sibling),
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
op->any.serial,
suffix);
break;
}
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
case STACK_OP_LOWER_BELOW:
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
{
meta_topic (META_DEBUG_STACK, "%sLOWER_BELOW(%s, %s; %ld)%s",
prefix,
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
window_desc,
get_window_desc (tracker, op->lower_below.sibling),
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
op->any.serial,
suffix);
break;
}
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
}
}
Fix warnings when building without verbose mode
2018-07-12 15:08:52 +00:00
#ifdef WITH_VERBOSE_MODE
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
static void
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
stack_dump (MetaStackTracker *tracker,
GArray *stack)
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
{
guint i;
meta_push_no_msg_prefix ();
stack-tracker: Clean up dumping
2014-07-10 20:12:05 +00:00
for (i = 0; i < stack->len; i++)
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
{
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
guint64 window = g_array_index (stack, guint64, i);
meta_topic (META_DEBUG_STACK, " %s", get_window_desc (tracker, window));
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
}
stack-tracker: Clean up dumping
2014-07-10 20:12:05 +00:00
meta_topic (META_DEBUG_STACK, "\n");
meta_pop_no_msg_prefix ();
}
Fix warnings when building without verbose mode
2018-07-12 15:08:52 +00:00
#endif /* WITH_VERBOSE_MODE */
stack-tracker: Clean up dumping
2014-07-10 20:12:05 +00:00
static void
meta_stack_tracker_dump (MetaStackTracker *tracker)
{
Fix warnings when building without verbose mode
2018-07-12 15:08:52 +00:00
#ifdef WITH_VERBOSE_MODE
stack-tracker: Clean up dumping
2014-07-10 20:12:05 +00:00
GList *l;
Always use the default screen GDK doesn't support multiple screens, so effectively we don't either. Lets stop pretending we do. This fixes a few -Wdeprecated warnings. https://bugzilla.gnome.org/show_bug.cgi?id=769070
2016-07-21 13:03:56 +00:00
meta_topic (META_DEBUG_STACK, "MetaStackTracker state\n");
stack-tracker: Clean up dumping
2014-07-10 20:12:05 +00:00
meta_push_no_msg_prefix ();
meta_topic (META_DEBUG_STACK, " xserver_serial: %ld\n", tracker->xserver_serial);
MetaStackTracker: eliminate the resynchronization process The step where we requery the stacking order from the server than combine it in an arbitrary fashion with Wayland windows can be eliminated by observing that we are the final authority for Wayland window stacking - so if we apply each X event that we receive from the X server to our stack in a way that leaves the X windows ordered in the same way as on the server, and apply events that we have stored locally in a way that doesn't affect the ordering of X windows, than we have a fully correct ordering of windows. Ordering this in the order of first applying the X event and then applying the local portion also means that as long as we had an up-to-date view of the X stack the composite operation will be identical to what was requested. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 17:41:27 +00:00
meta_topic (META_DEBUG_STACK, " verified_stack: ");
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
stack_dump (tracker, tracker->verified_stack);
stack-tracker: Clean up dumping
2014-07-10 20:12:05 +00:00
meta_topic (META_DEBUG_STACK, " unverified_predictions: [");
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
for (l = tracker->unverified_predictions->head; l; l = l->next)
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
{
MetaStackOp *op = l->data;
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
meta_stack_op_dump (tracker, op, "", l->next ? ", " : "");
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
}
meta_topic (META_DEBUG_STACK, "]\n");
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
if (tracker->predicted_stack)
{
meta_topic (META_DEBUG_STACK, "\n predicted_stack: ");
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
stack_dump (tracker, tracker->predicted_stack);
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
}
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
meta_pop_no_msg_prefix ();
Fix warnings when building without verbose mode
2018-07-12 15:08:52 +00:00
#endif /* WITH_VERBOSE_MODE */
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
}
static void
meta_stack_op_free (MetaStackOp *op)
{
g_slice_free (MetaStackOp, op);
}
static int
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
find_window (GArray *window_stack,
guint64 window)
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
{
guint i;
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
for (i = 0; i < window_stack->len; i++)
{
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
guint64 current = g_array_index (window_stack, guint64, i);
if (current == window)
return i;
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
}
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
return -1;
}
Move compositor-stack handling to MetaStackTracker In order to properly track the stacking order for override-redirect windows, move meta_compositor_sync_stack() call into MetaStackTracker. In the new location, we sync the stack as a before-redraw idle function, rather then using the freeze-thaw facilities of MetaStack. This is simpler, and also properly compresses multiple stack changes on notifications received from the X server. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-14 12:04:28 +00:00
/* Returns TRUE if stack was changed */
static gboolean
MetaStackTracker: eliminate the resynchronization process The step where we requery the stacking order from the server than combine it in an arbitrary fashion with Wayland windows can be eliminated by observing that we are the final authority for Wayland window stacking - so if we apply each X event that we receive from the X server to our stack in a way that leaves the X windows ordered in the same way as on the server, and apply events that we have stored locally in a way that doesn't affect the ordering of X windows, than we have a fully correct ordering of windows. Ordering this in the order of first applying the X event and then applying the local portion also means that as long as we had an up-to-date view of the X stack the composite operation will be identical to what was requested. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 17:41:27 +00:00
move_window_above (GArray *stack,
guint64 window,
int old_pos,
int above_pos,
ApplyFlags apply_flags)
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
{
int i;
MetaStackTracker: eliminate the resynchronization process The step where we requery the stacking order from the server than combine it in an arbitrary fashion with Wayland windows can be eliminated by observing that we are the final authority for Wayland window stacking - so if we apply each X event that we receive from the X server to our stack in a way that leaves the X windows ordered in the same way as on the server, and apply events that we have stored locally in a way that doesn't affect the ordering of X windows, than we have a fully correct ordering of windows. Ordering this in the order of first applying the X event and then applying the local portion also means that as long as we had an up-to-date view of the X stack the composite operation will be identical to what was requested. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 17:41:27 +00:00
gboolean can_restack_this_window =
(apply_flags & NO_RESTACK_X_WINDOWS) == 0 || !META_STACK_ID_IS_X11 (window);
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
if (old_pos < above_pos)
{
MetaStackTracker: eliminate the resynchronization process The step where we requery the stacking order from the server than combine it in an arbitrary fashion with Wayland windows can be eliminated by observing that we are the final authority for Wayland window stacking - so if we apply each X event that we receive from the X server to our stack in a way that leaves the X windows ordered in the same way as on the server, and apply events that we have stored locally in a way that doesn't affect the ordering of X windows, than we have a fully correct ordering of windows. Ordering this in the order of first applying the X event and then applying the local portion also means that as long as we had an up-to-date view of the X stack the composite operation will be identical to what was requested. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 17:41:27 +00:00
if ((apply_flags & IGNORE_NOOP_X_RESTACK) != 0)
{
gboolean found_x_window = FALSE;
for (i = old_pos + 1; i <= above_pos; i++)
if (META_STACK_ID_IS_X11 (g_array_index (stack, guint64, i)))
found_x_window = TRUE;
if (!found_x_window)
return FALSE;
}
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
for (i = old_pos; i < above_pos; i++)
MetaStackTracker: eliminate the resynchronization process The step where we requery the stacking order from the server than combine it in an arbitrary fashion with Wayland windows can be eliminated by observing that we are the final authority for Wayland window stacking - so if we apply each X event that we receive from the X server to our stack in a way that leaves the X windows ordered in the same way as on the server, and apply events that we have stored locally in a way that doesn't affect the ordering of X windows, than we have a fully correct ordering of windows. Ordering this in the order of first applying the X event and then applying the local portion also means that as long as we had an up-to-date view of the X stack the composite operation will be identical to what was requested. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 17:41:27 +00:00
{
if (!can_restack_this_window &&
META_STACK_ID_IS_X11 (g_array_index (stack, guint64, i + 1)))
break;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
MetaStackTracker: eliminate the resynchronization process The step where we requery the stacking order from the server than combine it in an arbitrary fashion with Wayland windows can be eliminated by observing that we are the final authority for Wayland window stacking - so if we apply each X event that we receive from the X server to our stack in a way that leaves the X windows ordered in the same way as on the server, and apply events that we have stored locally in a way that doesn't affect the ordering of X windows, than we have a fully correct ordering of windows. Ordering this in the order of first applying the X event and then applying the local portion also means that as long as we had an up-to-date view of the X stack the composite operation will be identical to what was requested. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 17:41:27 +00:00
g_array_index (stack, guint64, i) =
g_array_index (stack, guint64, i + 1);
}
g_array_index (stack, guint64, i) = window;
Move compositor-stack handling to MetaStackTracker In order to properly track the stacking order for override-redirect windows, move meta_compositor_sync_stack() call into MetaStackTracker. In the new location, we sync the stack as a before-redraw idle function, rather then using the freeze-thaw facilities of MetaStack. This is simpler, and also properly compresses multiple stack changes on notifications received from the X server. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-14 12:04:28 +00:00
MetaStackTracker: eliminate the resynchronization process The step where we requery the stacking order from the server than combine it in an arbitrary fashion with Wayland windows can be eliminated by observing that we are the final authority for Wayland window stacking - so if we apply each X event that we receive from the X server to our stack in a way that leaves the X windows ordered in the same way as on the server, and apply events that we have stored locally in a way that doesn't affect the ordering of X windows, than we have a fully correct ordering of windows. Ordering this in the order of first applying the X event and then applying the local portion also means that as long as we had an up-to-date view of the X stack the composite operation will be identical to what was requested. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 17:41:27 +00:00
return i != old_pos;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
}
else if (old_pos > above_pos + 1)
{
MetaStackTracker: eliminate the resynchronization process The step where we requery the stacking order from the server than combine it in an arbitrary fashion with Wayland windows can be eliminated by observing that we are the final authority for Wayland window stacking - so if we apply each X event that we receive from the X server to our stack in a way that leaves the X windows ordered in the same way as on the server, and apply events that we have stored locally in a way that doesn't affect the ordering of X windows, than we have a fully correct ordering of windows. Ordering this in the order of first applying the X event and then applying the local portion also means that as long as we had an up-to-date view of the X stack the composite operation will be identical to what was requested. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 17:41:27 +00:00
if ((apply_flags & IGNORE_NOOP_X_RESTACK) != 0)
{
gboolean found_x_window = FALSE;
for (i = above_pos + 1; i < old_pos; i++)
if (META_STACK_ID_IS_X11 (g_array_index (stack, guint64, i)))
found_x_window = TRUE;
if (!found_x_window)
return FALSE;
}
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
for (i = old_pos; i > above_pos + 1; i--)
MetaStackTracker: eliminate the resynchronization process The step where we requery the stacking order from the server than combine it in an arbitrary fashion with Wayland windows can be eliminated by observing that we are the final authority for Wayland window stacking - so if we apply each X event that we receive from the X server to our stack in a way that leaves the X windows ordered in the same way as on the server, and apply events that we have stored locally in a way that doesn't affect the ordering of X windows, than we have a fully correct ordering of windows. Ordering this in the order of first applying the X event and then applying the local portion also means that as long as we had an up-to-date view of the X stack the composite operation will be identical to what was requested. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 17:41:27 +00:00
{
if (!can_restack_this_window &&
META_STACK_ID_IS_X11 (g_array_index (stack, guint64, i - 1)))
break;
g_array_index (stack, guint64, i) =
g_array_index (stack, guint64, i - 1);
}
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
MetaStackTracker: eliminate the resynchronization process The step where we requery the stacking order from the server than combine it in an arbitrary fashion with Wayland windows can be eliminated by observing that we are the final authority for Wayland window stacking - so if we apply each X event that we receive from the X server to our stack in a way that leaves the X windows ordered in the same way as on the server, and apply events that we have stored locally in a way that doesn't affect the ordering of X windows, than we have a fully correct ordering of windows. Ordering this in the order of first applying the X event and then applying the local portion also means that as long as we had an up-to-date view of the X stack the composite operation will be identical to what was requested. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 17:41:27 +00:00
g_array_index (stack, guint64, i) = window;
Move compositor-stack handling to MetaStackTracker In order to properly track the stacking order for override-redirect windows, move meta_compositor_sync_stack() call into MetaStackTracker. In the new location, we sync the stack as a before-redraw idle function, rather then using the freeze-thaw facilities of MetaStack. This is simpler, and also properly compresses multiple stack changes on notifications received from the X server. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-14 12:04:28 +00:00
MetaStackTracker: eliminate the resynchronization process The step where we requery the stacking order from the server than combine it in an arbitrary fashion with Wayland windows can be eliminated by observing that we are the final authority for Wayland window stacking - so if we apply each X event that we receive from the X server to our stack in a way that leaves the X windows ordered in the same way as on the server, and apply events that we have stored locally in a way that doesn't affect the ordering of X windows, than we have a fully correct ordering of windows. Ordering this in the order of first applying the X event and then applying the local portion also means that as long as we had an up-to-date view of the X stack the composite operation will be identical to what was requested. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 17:41:27 +00:00
return i != old_pos;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
}
Move compositor-stack handling to MetaStackTracker In order to properly track the stacking order for override-redirect windows, move meta_compositor_sync_stack() call into MetaStackTracker. In the new location, we sync the stack as a before-redraw idle function, rather then using the freeze-thaw facilities of MetaStack. This is simpler, and also properly compresses multiple stack changes on notifications received from the X server. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-14 12:04:28 +00:00
else
return FALSE;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
}
Move compositor-stack handling to MetaStackTracker In order to properly track the stacking order for override-redirect windows, move meta_compositor_sync_stack() call into MetaStackTracker. In the new location, we sync the stack as a before-redraw idle function, rather then using the freeze-thaw facilities of MetaStack. This is simpler, and also properly compresses multiple stack changes on notifications received from the X server. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-14 12:04:28 +00:00
/* Returns TRUE if stack was changed */
static gboolean
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
meta_stack_op_apply (MetaStackTracker *tracker,
MetaStackOp *op,
MetaStackTracker: eliminate the resynchronization process The step where we requery the stacking order from the server than combine it in an arbitrary fashion with Wayland windows can be eliminated by observing that we are the final authority for Wayland window stacking - so if we apply each X event that we receive from the X server to our stack in a way that leaves the X windows ordered in the same way as on the server, and apply events that we have stored locally in a way that doesn't affect the ordering of X windows, than we have a fully correct ordering of windows. Ordering this in the order of first applying the X event and then applying the local portion also means that as long as we had an up-to-date view of the X stack the composite operation will be identical to what was requested. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 17:41:27 +00:00
GArray *stack,
ApplyFlags apply_flags)
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
{
switch (op->any.type)
{
case STACK_OP_ADD:
{
MetaStackTracker: eliminate the resynchronization process The step where we requery the stacking order from the server than combine it in an arbitrary fashion with Wayland windows can be eliminated by observing that we are the final authority for Wayland window stacking - so if we apply each X event that we receive from the X server to our stack in a way that leaves the X windows ordered in the same way as on the server, and apply events that we have stored locally in a way that doesn't affect the ordering of X windows, than we have a fully correct ordering of windows. Ordering this in the order of first applying the X event and then applying the local portion also means that as long as we had an up-to-date view of the X stack the composite operation will be identical to what was requested. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 17:41:27 +00:00
if (META_STACK_ID_IS_X11 (op->add.window) &&
(apply_flags & NO_RESTACK_X_WINDOWS) != 0)
return FALSE;
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
int old_pos = find_window (stack, op->add.window);
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
if (old_pos >= 0)
{
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
g_warning ("STACK_OP_ADD: window %s already in stack",
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
get_window_desc (tracker, op->add.window));
Move compositor-stack handling to MetaStackTracker In order to properly track the stacking order for override-redirect windows, move meta_compositor_sync_stack() call into MetaStackTracker. In the new location, we sync the stack as a before-redraw idle function, rather then using the freeze-thaw facilities of MetaStack. This is simpler, and also properly compresses multiple stack changes on notifications received from the X server. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-14 12:04:28 +00:00
return FALSE;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
}
g_array_append_val (stack, op->add.window);
Move compositor-stack handling to MetaStackTracker In order to properly track the stacking order for override-redirect windows, move meta_compositor_sync_stack() call into MetaStackTracker. In the new location, we sync the stack as a before-redraw idle function, rather then using the freeze-thaw facilities of MetaStack. This is simpler, and also properly compresses multiple stack changes on notifications received from the X server. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-14 12:04:28 +00:00
return TRUE;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
}
case STACK_OP_REMOVE:
{
MetaStackTracker: eliminate the resynchronization process The step where we requery the stacking order from the server than combine it in an arbitrary fashion with Wayland windows can be eliminated by observing that we are the final authority for Wayland window stacking - so if we apply each X event that we receive from the X server to our stack in a way that leaves the X windows ordered in the same way as on the server, and apply events that we have stored locally in a way that doesn't affect the ordering of X windows, than we have a fully correct ordering of windows. Ordering this in the order of first applying the X event and then applying the local portion also means that as long as we had an up-to-date view of the X stack the composite operation will be identical to what was requested. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 17:41:27 +00:00
if (META_STACK_ID_IS_X11 (op->remove.window) &&
(apply_flags & NO_RESTACK_X_WINDOWS) != 0)
return FALSE;
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
int old_pos = find_window (stack, op->remove.window);
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
if (old_pos < 0)
{
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
g_warning ("STACK_OP_REMOVE: window %s not in stack",
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
get_window_desc (tracker, op->remove.window));
Move compositor-stack handling to MetaStackTracker In order to properly track the stacking order for override-redirect windows, move meta_compositor_sync_stack() call into MetaStackTracker. In the new location, we sync the stack as a before-redraw idle function, rather then using the freeze-thaw facilities of MetaStack. This is simpler, and also properly compresses multiple stack changes on notifications received from the X server. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-14 12:04:28 +00:00
return FALSE;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
}
g_array_remove_index (stack, old_pos);
Move compositor-stack handling to MetaStackTracker In order to properly track the stacking order for override-redirect windows, move meta_compositor_sync_stack() call into MetaStackTracker. In the new location, we sync the stack as a before-redraw idle function, rather then using the freeze-thaw facilities of MetaStack. This is simpler, and also properly compresses multiple stack changes on notifications received from the X server. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-14 12:04:28 +00:00
return TRUE;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
}
case STACK_OP_RAISE_ABOVE:
{
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
int old_pos = find_window (stack, op->raise_above.window);
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
int above_pos;
if (old_pos < 0)
{
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
g_warning ("STACK_OP_RAISE_ABOVE: window %s not in stack",
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
get_window_desc (tracker, op->raise_above.window));
Move compositor-stack handling to MetaStackTracker In order to properly track the stacking order for override-redirect windows, move meta_compositor_sync_stack() call into MetaStackTracker. In the new location, we sync the stack as a before-redraw idle function, rather then using the freeze-thaw facilities of MetaStack. This is simpler, and also properly compresses multiple stack changes on notifications received from the X server. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-14 12:04:28 +00:00
return FALSE;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
}
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
if (op->raise_above.sibling)
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
{
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
above_pos = find_window (stack, op->raise_above.sibling);
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
if (above_pos < 0)
{
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
g_warning ("STACK_OP_RAISE_ABOVE: sibling window %s not in stack",
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
get_window_desc (tracker, op->raise_above.sibling));
Move compositor-stack handling to MetaStackTracker In order to properly track the stacking order for override-redirect windows, move meta_compositor_sync_stack() call into MetaStackTracker. In the new location, we sync the stack as a before-redraw idle function, rather then using the freeze-thaw facilities of MetaStack. This is simpler, and also properly compresses multiple stack changes on notifications received from the X server. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-14 12:04:28 +00:00
return FALSE;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
}
}
else
{
above_pos = -1;
}
MetaStackTracker: eliminate the resynchronization process The step where we requery the stacking order from the server than combine it in an arbitrary fashion with Wayland windows can be eliminated by observing that we are the final authority for Wayland window stacking - so if we apply each X event that we receive from the X server to our stack in a way that leaves the X windows ordered in the same way as on the server, and apply events that we have stored locally in a way that doesn't affect the ordering of X windows, than we have a fully correct ordering of windows. Ordering this in the order of first applying the X event and then applying the local portion also means that as long as we had an up-to-date view of the X stack the composite operation will be identical to what was requested. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 17:41:27 +00:00
return move_window_above (stack, op->raise_above.window, old_pos, above_pos,
apply_flags);
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
}
case STACK_OP_LOWER_BELOW:
{
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
int old_pos = find_window (stack, op->lower_below.window);
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
int above_pos;
if (old_pos < 0)
{
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
g_warning ("STACK_OP_LOWER_BELOW: window %s not in stack",
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
get_window_desc (tracker, op->lower_below.window));
Move compositor-stack handling to MetaStackTracker In order to properly track the stacking order for override-redirect windows, move meta_compositor_sync_stack() call into MetaStackTracker. In the new location, we sync the stack as a before-redraw idle function, rather then using the freeze-thaw facilities of MetaStack. This is simpler, and also properly compresses multiple stack changes on notifications received from the X server. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-14 12:04:28 +00:00
return FALSE;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
}
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
if (op->lower_below.sibling)
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
{
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
int below_pos = find_window (stack, op->lower_below.sibling);
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
if (below_pos < 0)
{
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
g_warning ("STACK_OP_LOWER_BELOW: sibling window %s not in stack",
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
get_window_desc (tracker, op->lower_below.sibling));
Move compositor-stack handling to MetaStackTracker In order to properly track the stacking order for override-redirect windows, move meta_compositor_sync_stack() call into MetaStackTracker. In the new location, we sync the stack as a before-redraw idle function, rather then using the freeze-thaw facilities of MetaStack. This is simpler, and also properly compresses multiple stack changes on notifications received from the X server. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-14 12:04:28 +00:00
return FALSE;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
}
above_pos = below_pos - 1;
}
else
{
above_pos = stack->len - 1;
}
MetaStackTracker: eliminate the resynchronization process The step where we requery the stacking order from the server than combine it in an arbitrary fashion with Wayland windows can be eliminated by observing that we are the final authority for Wayland window stacking - so if we apply each X event that we receive from the X server to our stack in a way that leaves the X windows ordered in the same way as on the server, and apply events that we have stored locally in a way that doesn't affect the ordering of X windows, than we have a fully correct ordering of windows. Ordering this in the order of first applying the X event and then applying the local portion also means that as long as we had an up-to-date view of the X stack the composite operation will be identical to what was requested. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 17:41:27 +00:00
return move_window_above (stack, op->lower_below.window, old_pos, above_pos,
apply_flags);
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
}
}
Move compositor-stack handling to MetaStackTracker In order to properly track the stacking order for override-redirect windows, move meta_compositor_sync_stack() call into MetaStackTracker. In the new location, we sync the stack as a before-redraw idle function, rather then using the freeze-thaw facilities of MetaStack. This is simpler, and also properly compresses multiple stack changes on notifications received from the X server. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-14 12:04:28 +00:00
g_assert_not_reached ();
return FALSE;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
}
static GArray *
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
copy_stack (GArray *stack)
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
{
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
GArray *copy = g_array_sized_new (FALSE, FALSE, sizeof (guint64), stack->len);
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
g_array_set_size (copy, stack->len);
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
memcpy (copy->data, stack->data, sizeof (guint64) * stack->len);
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
return copy;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
}
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
static void
Make stack tracker work without X11 https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 20:43:28 +00:00
query_xserver_stack (MetaDisplay *display,
MetaStackTracker *tracker)
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
{
Make stack tracker work without X11 https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 20:43:28 +00:00
MetaX11Display *x11_display = display->x11_display;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
Window ignored1, ignored2;
Window *children;
guint n_children;
Make stack tracker work without X11 https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 20:43:28 +00:00
guint i, old_len;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
Move stack tracking and guard_window outside of MetaScreen Move stack, stack_tracker to MetaDisplay guard_window to MetaX11Display https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 17:03:51 +00:00
tracker->xserver_serial = XNextRequest (x11_display->xdisplay);
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
Move stack tracking and guard_window outside of MetaScreen Move stack, stack_tracker to MetaDisplay guard_window to MetaX11Display https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 17:03:51 +00:00
XQueryTree (x11_display->xdisplay,
x11_display->xroot,
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
&ignored1, &ignored2, &children, &n_children);
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
Make stack tracker work without X11 https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 20:43:28 +00:00
old_len = tracker->verified_stack->len;
g_array_set_size (tracker->verified_stack, old_len + n_children);
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
for (i = 0; i < n_children; i++)
Make stack tracker work without X11 https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 20:43:28 +00:00
g_array_index (tracker->verified_stack, guint64, old_len + i) = children[i];
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
XFree (children);
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
}
core: Prepare MetaStackTracker for X11 display being closed If the display is closed prematurely, go through all windows that look X11-y and remove them for future calculations. This is not strictly needed as Xwayland should shut down orderly (thus no client windows be there), but doesn't hurt to prepare in advance for the cases where it might not be the case. https://gitlab.gnome.org/GNOME/mutter/merge_requests/709
2019-05-24 18:04:09 +00:00
static void
drop_x11_windows (MetaDisplay *display,
MetaStackTracker *tracker)
{
GArray *new_stack;
GList *l;
int i;
tracker->xserver_serial = 0;
new_stack = g_array_new (FALSE, FALSE, sizeof (guint64));
for (i = 0; i < tracker->verified_stack->len; i++)
{
guint64 window = g_array_index (tracker->verified_stack, guint64, i);
if (!META_STACK_ID_IS_X11 (window))
g_array_append_val (new_stack, window);
}
g_array_unref (tracker->verified_stack);
tracker->verified_stack = new_stack;
l = tracker->unverified_predictions->head;
while (l)
{
MetaStackOp *op = l->data;
GList *next = l->next;
if (META_STACK_ID_IS_X11 (op->any.window))
g_queue_remove (tracker->unverified_predictions, op);
l = next;
}
}
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
MetaStackTracker *
Move stack tracking and guard_window outside of MetaScreen Move stack, stack_tracker to MetaDisplay guard_window to MetaX11Display https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 17:03:51 +00:00
meta_stack_tracker_new (MetaDisplay *display)
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
{
MetaStackTracker *tracker;
tracker = g_new0 (MetaStackTracker, 1);
Move stack tracking and guard_window outside of MetaScreen Move stack, stack_tracker to MetaDisplay guard_window to MetaX11Display https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 17:03:51 +00:00
tracker->display = display;
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
Make stack tracker work without X11 https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 20:43:28 +00:00
tracker->verified_stack = g_array_new (FALSE, FALSE, sizeof (guint64));
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
tracker->unverified_predictions = g_queue_new ();
Make stack tracker work without X11 https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 20:43:28 +00:00
g_signal_connect (display,
core: Split x11-display initialization in 2 signals We have a "setup" phase, used internally to initialize early the x11 side of things like the stack tracker, and an "opened" phase where other upper parts may hook up to. This latter phase is delayed during initialization so the upper parts have a change to connect to on plugin creation. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/771
2019-09-11 20:26:49 +00:00
"x11-display-setup",
Make stack tracker work without X11 https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 20:43:28 +00:00
G_CALLBACK (query_xserver_stack),
tracker);
core: Prepare MetaStackTracker for X11 display being closed If the display is closed prematurely, go through all windows that look X11-y and remove them for future calculations. This is not strictly needed as Xwayland should shut down orderly (thus no client windows be there), but doesn't hurt to prepare in advance for the cases where it might not be the case. https://gitlab.gnome.org/GNOME/mutter/merge_requests/709
2019-05-24 18:04:09 +00:00
g_signal_connect (display,
"x11-display-closing",
G_CALLBACK (drop_x11_windows),
tracker);
Make stack tracker work without X11 https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 20:43:28 +00:00
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
meta_stack_tracker_dump (tracker);
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
return tracker;
}
void
meta_stack_tracker_free (MetaStackTracker *tracker)
{
Use "later functions" to fix priority problems with Clutter redraw There was a problem where if, for example, a restack was triggered out of a clutter event handler, then after Clutter processed the events, it would proceed immmediately on to repaint the stage without ever returning control to the GLib main loop. So even though we had an idle handler installed with a higher priority than the Clutter stage repainting the clutter stage repainting would happen first and we'd get a wrong frame. Fix this by introducing the idea of "later functions", which abstract the idea of "doing something later" away from g_idle_add() and use a combination of GLib idle functions and Clutter "repaint functions" to get our callbacks triggered at the right time, even when they are installed from a clutter event handler. https://bugzilla.gnome.org/show_bug.cgi?id=596334 This also resolve a FIXME where MUTTER_PRIORITY_BEFORE_REDRAW could starve stage repainting.
2009-09-25 19:47:22 +00:00
if (tracker->sync_stack_later)
meta_later_remove (tracker->sync_stack_later);
Move compositor-stack handling to MetaStackTracker In order to properly track the stacking order for override-redirect windows, move meta_compositor_sync_stack() call into MetaStackTracker. In the new location, we sync the stack as a before-redraw idle function, rather then using the freeze-thaw facilities of MetaStack. This is simpler, and also properly compresses multiple stack changes on notifications received from the X server. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-14 12:04:28 +00:00
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
g_array_free (tracker->verified_stack, TRUE);
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
if (tracker->predicted_stack)
g_array_free (tracker->predicted_stack, TRUE);
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
g_queue_foreach (tracker->unverified_predictions, (GFunc)meta_stack_op_free, NULL);
g_queue_free (tracker->unverified_predictions);
tracker->unverified_predictions = NULL;
meta_stack_tracker_free(): fix memory leak https://bugzilla.gnome.org/show_bug.cgi?id=672640
2012-03-23 07:59:11 +00:00
Make stack tracker work without X11 https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 20:43:28 +00:00
g_signal_handlers_disconnect_by_func (tracker->display,
(gpointer)query_xserver_stack,
tracker);
core: Prepare MetaStackTracker for X11 display being closed If the display is closed prematurely, go through all windows that look X11-y and remove them for future calculations. This is not strictly needed as Xwayland should shut down orderly (thus no client windows be there), but doesn't hurt to prepare in advance for the cases where it might not be the case. https://gitlab.gnome.org/GNOME/mutter/merge_requests/709
2019-05-24 18:04:09 +00:00
g_signal_handlers_disconnect_by_func (tracker->display,
drop_x11_windows,
tracker);
Make stack tracker work without X11 https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 20:43:28 +00:00
meta_stack_tracker_free(): fix memory leak https://bugzilla.gnome.org/show_bug.cgi?id=672640
2012-03-23 07:59:11 +00:00
g_free (tracker);
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
}
static void
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
stack_tracker_apply_prediction (MetaStackTracker *tracker,
MetaStackOp *op)
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
{
MetaStackTracker: make sure all stack ops are freed eventually If we apply a prediction immediately instead of queueing, we should also free the operation immediately. If we discard the prediction queue because we resync fully, we need to free each operation too. https://bugzilla.gnome.org/show_bug.cgi?id=729732
2014-05-07 16:25:58 +00:00
gboolean free_at_end = FALSE;
MetaStackTracker: optimize out unnecessary X restacking We have a quite accurate view of the X stack, so there's no good reason to ask the X server to do restacking that has no effect. (Restackings that have no effect on either X windows or Wayland windows were generally optimized out in the synchronization code, but in other cases like moving an X window that is only beneath Wayland windows to the top of the stack we would make such requests.) Removing such requests: - Is a small efficiency win in itself - Allows us to immediately go ahead and apply Wayland changes to the verified stack - Prevents queued Wayland changes piling up waiting for an X event that will never be received, since the X server will not send confirmation of no-op restacks. Since such operations may still have an effect on the relative stacking of X and Wayland windows, we need to continue applying them to the local stack. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-10 17:06:28 +00:00
/* If this operation doesn't involve restacking X windows then it's
* implicitly verified. We can apply it immediately unless there
* are outstanding X restacks that haven't yet been confirmed.
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
*/
MetaStackTracker: optimize out unnecessary X restacking We have a quite accurate view of the X stack, so there's no good reason to ask the X server to do restacking that has no effect. (Restackings that have no effect on either X windows or Wayland windows were generally optimized out in the synchronization code, but in other cases like moving an X window that is only beneath Wayland windows to the top of the stack we would make such requests.) Removing such requests: - Is a small efficiency win in itself - Allows us to immediately go ahead and apply Wayland changes to the verified stack - Prevents queued Wayland changes piling up waiting for an X event that will never be received, since the X server will not send confirmation of no-op restacks. Since such operations may still have an effect on the relative stacking of X and Wayland windows, we need to continue applying them to the local stack. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-10 17:06:28 +00:00
if (op->any.serial == 0 &&
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
tracker->unverified_predictions->length == 0)
{
MetaStackTracker: eliminate the resynchronization process The step where we requery the stacking order from the server than combine it in an arbitrary fashion with Wayland windows can be eliminated by observing that we are the final authority for Wayland window stacking - so if we apply each X event that we receive from the X server to our stack in a way that leaves the X windows ordered in the same way as on the server, and apply events that we have stored locally in a way that doesn't affect the ordering of X windows, than we have a fully correct ordering of windows. Ordering this in the order of first applying the X event and then applying the local portion also means that as long as we had an up-to-date view of the X stack the composite operation will be identical to what was requested. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 17:41:27 +00:00
if (meta_stack_op_apply (tracker, op, tracker->verified_stack, APPLY_DEFAULT))
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
meta_stack_tracker_queue_sync_stack (tracker);
MetaStackTracker: make sure all stack ops are freed eventually If we apply a prediction immediately instead of queueing, we should also free the operation immediately. If we discard the prediction queue because we resync fully, we need to free each operation too. https://bugzilla.gnome.org/show_bug.cgi?id=729732
2014-05-07 16:25:58 +00:00
free_at_end = TRUE;
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
}
else
{
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
meta_stack_op_dump (tracker, op, "Predicting: ", "\n");
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
g_queue_push_tail (tracker->unverified_predictions, op);
}
Move compositor-stack handling to MetaStackTracker In order to properly track the stacking order for override-redirect windows, move meta_compositor_sync_stack() call into MetaStackTracker. In the new location, we sync the stack as a before-redraw idle function, rather then using the freeze-thaw facilities of MetaStack. This is simpler, and also properly compresses multiple stack changes on notifications received from the X server. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-14 12:04:28 +00:00
if (!tracker->predicted_stack ||
MetaStackTracker: eliminate the resynchronization process The step where we requery the stacking order from the server than combine it in an arbitrary fashion with Wayland windows can be eliminated by observing that we are the final authority for Wayland window stacking - so if we apply each X event that we receive from the X server to our stack in a way that leaves the X windows ordered in the same way as on the server, and apply events that we have stored locally in a way that doesn't affect the ordering of X windows, than we have a fully correct ordering of windows. Ordering this in the order of first applying the X event and then applying the local portion also means that as long as we had an up-to-date view of the X stack the composite operation will be identical to what was requested. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 17:41:27 +00:00
meta_stack_op_apply (tracker, op, tracker->predicted_stack, APPLY_DEFAULT))
Move compositor-stack handling to MetaStackTracker In order to properly track the stacking order for override-redirect windows, move meta_compositor_sync_stack() call into MetaStackTracker. In the new location, we sync the stack as a before-redraw idle function, rather then using the freeze-thaw facilities of MetaStack. This is simpler, and also properly compresses multiple stack changes on notifications received from the X server. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-14 12:04:28 +00:00
meta_stack_tracker_queue_sync_stack (tracker);
MetaStackTracker: make sure all stack ops are freed eventually If we apply a prediction immediately instead of queueing, we should also free the operation immediately. If we discard the prediction queue because we resync fully, we need to free each operation too. https://bugzilla.gnome.org/show_bug.cgi?id=729732
2014-05-07 16:25:58 +00:00
if (free_at_end)
meta_stack_op_free (op);
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
meta_stack_tracker_dump (tracker);
}
void
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
meta_stack_tracker_record_add (MetaStackTracker *tracker,
guint64 window,
gulong serial)
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
{
MetaStackOp *op = g_slice_new (MetaStackOp);
op->any.type = STACK_OP_ADD;
op->any.serial = serial;
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
op->any.window = window;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
stack_tracker_apply_prediction (tracker, op);
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
}
void
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
meta_stack_tracker_record_remove (MetaStackTracker *tracker,
guint64 window,
gulong serial)
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
{
MetaStackOp *op = g_slice_new (MetaStackOp);
op->any.type = STACK_OP_REMOVE;
op->any.serial = serial;
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
op->any.window = window;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
stack_tracker_apply_prediction (tracker, op);
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
}
MetaStackTracker: make functions used only internally static Now that all actual stack shuffle is handled inside stack-tracker.c, we can make meta_stack_tracker_record_[raise_above/lower_below] internal to that file and remove the unused meta_stack_tracker_record_lower(). https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-11 22:00:08 +00:00
static void
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
meta_stack_tracker_record_raise_above (MetaStackTracker *tracker,
guint64 window,
guint64 sibling,
gulong serial)
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
{
MetaStackOp *op = g_slice_new (MetaStackOp);
op->any.type = STACK_OP_RAISE_ABOVE;
op->any.serial = serial;
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
op->any.window = window;
op->raise_above.sibling = sibling;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
stack_tracker_apply_prediction (tracker, op);
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
}
MetaStackTracker: make functions used only internally static Now that all actual stack shuffle is handled inside stack-tracker.c, we can make meta_stack_tracker_record_[raise_above/lower_below] internal to that file and remove the unused meta_stack_tracker_record_lower(). https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-11 22:00:08 +00:00
static void
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
meta_stack_tracker_record_lower_below (MetaStackTracker *tracker,
guint64 window,
guint64 sibling,
gulong serial)
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
{
MetaStackOp *op = g_slice_new (MetaStackOp);
op->any.type = STACK_OP_LOWER_BELOW;
op->any.serial = serial;
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
op->any.window = window;
op->lower_below.sibling = sibling;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
stack_tracker_apply_prediction (tracker, op);
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
}
MetaStackTracker: eliminate the resynchronization process The step where we requery the stacking order from the server than combine it in an arbitrary fashion with Wayland windows can be eliminated by observing that we are the final authority for Wayland window stacking - so if we apply each X event that we receive from the X server to our stack in a way that leaves the X windows ordered in the same way as on the server, and apply events that we have stored locally in a way that doesn't affect the ordering of X windows, than we have a fully correct ordering of windows. Ordering this in the order of first applying the X event and then applying the local portion also means that as long as we had an up-to-date view of the X stack the composite operation will be identical to what was requested. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 17:41:27 +00:00
static void
stack_tracker_event_received (MetaStackTracker *tracker,
MetaStackOp *op)
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
{
MetaStackTracker: eliminate the resynchronization process The step where we requery the stacking order from the server than combine it in an arbitrary fashion with Wayland windows can be eliminated by observing that we are the final authority for Wayland window stacking - so if we apply each X event that we receive from the X server to our stack in a way that leaves the X windows ordered in the same way as on the server, and apply events that we have stored locally in a way that doesn't affect the ordering of X windows, than we have a fully correct ordering of windows. Ordering this in the order of first applying the X event and then applying the local portion also means that as long as we had an up-to-date view of the X stack the composite operation will be identical to what was requested. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 17:41:27 +00:00
gboolean need_sync = FALSE;
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
MetaStackTracker: eliminate the resynchronization process The step where we requery the stacking order from the server than combine it in an arbitrary fashion with Wayland windows can be eliminated by observing that we are the final authority for Wayland window stacking - so if we apply each X event that we receive from the X server to our stack in a way that leaves the X windows ordered in the same way as on the server, and apply events that we have stored locally in a way that doesn't affect the ordering of X windows, than we have a fully correct ordering of windows. Ordering this in the order of first applying the X event and then applying the local portion also means that as long as we had an up-to-date view of the X stack the composite operation will be identical to what was requested. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 17:41:27 +00:00
/* If the event is older than our initial query, then it's
* already included in our tree. Just ignore it. */
if (op->any.serial < tracker->xserver_serial)
return;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
MetaStackTracker: eliminate the resynchronization process The step where we requery the stacking order from the server than combine it in an arbitrary fashion with Wayland windows can be eliminated by observing that we are the final authority for Wayland window stacking - so if we apply each X event that we receive from the X server to our stack in a way that leaves the X windows ordered in the same way as on the server, and apply events that we have stored locally in a way that doesn't affect the ordering of X windows, than we have a fully correct ordering of windows. Ordering this in the order of first applying the X event and then applying the local portion also means that as long as we had an up-to-date view of the X stack the composite operation will be identical to what was requested. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 17:41:27 +00:00
meta_stack_op_dump (tracker, op, "Stack op event received: ", "\n");
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
MetaStackTracker: eliminate the resynchronization process The step where we requery the stacking order from the server than combine it in an arbitrary fashion with Wayland windows can be eliminated by observing that we are the final authority for Wayland window stacking - so if we apply each X event that we receive from the X server to our stack in a way that leaves the X windows ordered in the same way as on the server, and apply events that we have stored locally in a way that doesn't affect the ordering of X windows, than we have a fully correct ordering of windows. Ordering this in the order of first applying the X event and then applying the local portion also means that as long as we had an up-to-date view of the X stack the composite operation will be identical to what was requested. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 17:41:27 +00:00
/* First we apply any operations that we have queued up that depended
* on X operations *older* than what we received .. those operations
* must have been ignored by the X server, so we just apply the
* operations we have as best as possible while not moving windows.
*/
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
while (tracker->unverified_predictions->head)
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
{
MetaStackTracker: eliminate the resynchronization process The step where we requery the stacking order from the server than combine it in an arbitrary fashion with Wayland windows can be eliminated by observing that we are the final authority for Wayland window stacking - so if we apply each X event that we receive from the X server to our stack in a way that leaves the X windows ordered in the same way as on the server, and apply events that we have stored locally in a way that doesn't affect the ordering of X windows, than we have a fully correct ordering of windows. Ordering this in the order of first applying the X event and then applying the local portion also means that as long as we had an up-to-date view of the X stack the composite operation will be identical to what was requested. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 17:41:27 +00:00
MetaStackOp *queued_op = tracker->unverified_predictions->head->data;
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
MetaStackTracker: eliminate the resynchronization process The step where we requery the stacking order from the server than combine it in an arbitrary fashion with Wayland windows can be eliminated by observing that we are the final authority for Wayland window stacking - so if we apply each X event that we receive from the X server to our stack in a way that leaves the X windows ordered in the same way as on the server, and apply events that we have stored locally in a way that doesn't affect the ordering of X windows, than we have a fully correct ordering of windows. Ordering this in the order of first applying the X event and then applying the local portion also means that as long as we had an up-to-date view of the X stack the composite operation will be identical to what was requested. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 17:41:27 +00:00
if (queued_op->any.serial >= op->any.serial)
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
break;
MetaStackTracker: eliminate the resynchronization process The step where we requery the stacking order from the server than combine it in an arbitrary fashion with Wayland windows can be eliminated by observing that we are the final authority for Wayland window stacking - so if we apply each X event that we receive from the X server to our stack in a way that leaves the X windows ordered in the same way as on the server, and apply events that we have stored locally in a way that doesn't affect the ordering of X windows, than we have a fully correct ordering of windows. Ordering this in the order of first applying the X event and then applying the local portion also means that as long as we had an up-to-date view of the X stack the composite operation will be identical to what was requested. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 17:41:27 +00:00
meta_stack_op_apply (tracker, queued_op, tracker->verified_stack,
NO_RESTACK_X_WINDOWS);
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
g_queue_pop_head (tracker->unverified_predictions);
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
meta_stack_op_free (queued_op);
MetaStackTracker: eliminate the resynchronization process The step where we requery the stacking order from the server than combine it in an arbitrary fashion with Wayland windows can be eliminated by observing that we are the final authority for Wayland window stacking - so if we apply each X event that we receive from the X server to our stack in a way that leaves the X windows ordered in the same way as on the server, and apply events that we have stored locally in a way that doesn't affect the ordering of X windows, than we have a fully correct ordering of windows. Ordering this in the order of first applying the X event and then applying the local portion also means that as long as we had an up-to-date view of the X stack the composite operation will be identical to what was requested. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 17:41:27 +00:00
need_sync = TRUE;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
}
MetaStackTracker: eliminate the resynchronization process The step where we requery the stacking order from the server than combine it in an arbitrary fashion with Wayland windows can be eliminated by observing that we are the final authority for Wayland window stacking - so if we apply each X event that we receive from the X server to our stack in a way that leaves the X windows ordered in the same way as on the server, and apply events that we have stored locally in a way that doesn't affect the ordering of X windows, than we have a fully correct ordering of windows. Ordering this in the order of first applying the X event and then applying the local portion also means that as long as we had an up-to-date view of the X stack the composite operation will be identical to what was requested. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 17:41:27 +00:00
/* Then we apply the received event. If it's a spontaneous event
* based on stacking we didn't trigger, this is the only handling. If we
* triggered it, we do the X restacking here, and then any residual
* local-only Wayland stacking below.
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
*/
MetaStackTracker: eliminate the resynchronization process The step where we requery the stacking order from the server than combine it in an arbitrary fashion with Wayland windows can be eliminated by observing that we are the final authority for Wayland window stacking - so if we apply each X event that we receive from the X server to our stack in a way that leaves the X windows ordered in the same way as on the server, and apply events that we have stored locally in a way that doesn't affect the ordering of X windows, than we have a fully correct ordering of windows. Ordering this in the order of first applying the X event and then applying the local portion also means that as long as we had an up-to-date view of the X stack the composite operation will be identical to what was requested. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 17:41:27 +00:00
if (meta_stack_op_apply (tracker, op, tracker->verified_stack,
IGNORE_NOOP_X_RESTACK))
need_sync = TRUE;
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
MetaStackTracker: eliminate the resynchronization process The step where we requery the stacking order from the server than combine it in an arbitrary fashion with Wayland windows can be eliminated by observing that we are the final authority for Wayland window stacking - so if we apply each X event that we receive from the X server to our stack in a way that leaves the X windows ordered in the same way as on the server, and apply events that we have stored locally in a way that doesn't affect the ordering of X windows, than we have a fully correct ordering of windows. Ordering this in the order of first applying the X event and then applying the local portion also means that as long as we had an up-to-date view of the X stack the composite operation will be identical to what was requested. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 17:41:27 +00:00
/* What is left to process is the prediction corresponding to the event
* (if any), and then any subsequent Wayland-only events we can just
* go ahead and do now.
*/
while (tracker->unverified_predictions->head)
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
{
MetaStackTracker: eliminate the resynchronization process The step where we requery the stacking order from the server than combine it in an arbitrary fashion with Wayland windows can be eliminated by observing that we are the final authority for Wayland window stacking - so if we apply each X event that we receive from the X server to our stack in a way that leaves the X windows ordered in the same way as on the server, and apply events that we have stored locally in a way that doesn't affect the ordering of X windows, than we have a fully correct ordering of windows. Ordering this in the order of first applying the X event and then applying the local portion also means that as long as we had an up-to-date view of the X stack the composite operation will be identical to what was requested. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 17:41:27 +00:00
MetaStackOp *queued_op = tracker->unverified_predictions->head->data;
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
MetaStackTracker: eliminate the resynchronization process The step where we requery the stacking order from the server than combine it in an arbitrary fashion with Wayland windows can be eliminated by observing that we are the final authority for Wayland window stacking - so if we apply each X event that we receive from the X server to our stack in a way that leaves the X windows ordered in the same way as on the server, and apply events that we have stored locally in a way that doesn't affect the ordering of X windows, than we have a fully correct ordering of windows. Ordering this in the order of first applying the X event and then applying the local portion also means that as long as we had an up-to-date view of the X stack the composite operation will be identical to what was requested. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 17:41:27 +00:00
if (queued_op->any.serial > op->any.serial)
break;
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
MetaStackTracker: eliminate the resynchronization process The step where we requery the stacking order from the server than combine it in an arbitrary fashion with Wayland windows can be eliminated by observing that we are the final authority for Wayland window stacking - so if we apply each X event that we receive from the X server to our stack in a way that leaves the X windows ordered in the same way as on the server, and apply events that we have stored locally in a way that doesn't affect the ordering of X windows, than we have a fully correct ordering of windows. Ordering this in the order of first applying the X event and then applying the local portion also means that as long as we had an up-to-date view of the X stack the composite operation will be identical to what was requested. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 17:41:27 +00:00
meta_stack_op_apply (tracker, queued_op, tracker->verified_stack,
NO_RESTACK_X_WINDOWS);
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
MetaStackTracker: eliminate the resynchronization process The step where we requery the stacking order from the server than combine it in an arbitrary fashion with Wayland windows can be eliminated by observing that we are the final authority for Wayland window stacking - so if we apply each X event that we receive from the X server to our stack in a way that leaves the X windows ordered in the same way as on the server, and apply events that we have stored locally in a way that doesn't affect the ordering of X windows, than we have a fully correct ordering of windows. Ordering this in the order of first applying the X event and then applying the local portion also means that as long as we had an up-to-date view of the X stack the composite operation will be identical to what was requested. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 17:41:27 +00:00
g_queue_pop_head (tracker->unverified_predictions);
meta_stack_op_free (queued_op);
need_sync = TRUE;
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
}
MetaStackTracker: eliminate the resynchronization process The step where we requery the stacking order from the server than combine it in an arbitrary fashion with Wayland windows can be eliminated by observing that we are the final authority for Wayland window stacking - so if we apply each X event that we receive from the X server to our stack in a way that leaves the X windows ordered in the same way as on the server, and apply events that we have stored locally in a way that doesn't affect the ordering of X windows, than we have a fully correct ordering of windows. Ordering this in the order of first applying the X event and then applying the local portion also means that as long as we had an up-to-date view of the X stack the composite operation will be identical to what was requested. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 17:41:27 +00:00
if (need_sync)
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
{
MetaStackTracker: Avoid queueing resync for obvious no-ops Since we can't distinguish a ConfigureEvent that indicates a raise from a ConfigureEvent that indicates a move, we get lots of STACK_OP_RAISE_ABOVE events for windows that are already in the right place in the stacking order. Avoid queueing a restack in that case. https://bugzilla.gnome.org/show_bug.cgi?id=634771
2010-11-13 19:07:07 +00:00
if (tracker->predicted_stack)
{
g_array_free (tracker->predicted_stack, TRUE);
tracker->predicted_stack = NULL;
}
meta_stack_tracker_queue_sync_stack (tracker);
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
}
meta_stack_tracker_dump (tracker);
}
void
meta_stack_tracker_create_event (MetaStackTracker *tracker,
XCreateWindowEvent *event)
{
MetaStackOp op;
op.any.type = STACK_OP_ADD;
op.any.serial = event->serial;
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
op.add.window = event->window;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
stack_tracker_event_received (tracker, &op);
}
void
meta_stack_tracker_destroy_event (MetaStackTracker *tracker,
XDestroyWindowEvent *event)
{
MetaStackOp op;
op.any.type = STACK_OP_REMOVE;
op.any.serial = event->serial;
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
op.remove.window = event->window;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
stack_tracker_event_received (tracker, &op);
}
void
meta_stack_tracker_reparent_event (MetaStackTracker *tracker,
XReparentEvent *event)
{
if (event->parent == event->event)
{
MetaStackOp op;
op.any.type = STACK_OP_ADD;
op.any.serial = event->serial;
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
op.add.window = event->window;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
stack_tracker_event_received (tracker, &op);
}
else
{
MetaStackOp op;
op.any.type = STACK_OP_REMOVE;
op.any.serial = event->serial;
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
op.remove.window = event->window;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
stack_tracker_event_received (tracker, &op);
}
}
void
meta_stack_tracker_configure_event (MetaStackTracker *tracker,
XConfigureEvent *event)
{
MetaStackOp op;
op.any.type = STACK_OP_RAISE_ABOVE;
op.any.serial = event->serial;
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
op.raise_above.window = event->window;
op.raise_above.sibling = event->above;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
stack_tracker_event_received (tracker, &op);
}
stack-tracker: Don't sort O-R's under guard window on top As of "stack-tracker: Keep override redirect windows on top" (e3d5bc077d0ee5dc0368f99d22ce352c696644b9), we always sorted all override redirect on top of regular windows, as so is expected by regular override redirect windows. This had an unwanted consequence, however, which is that we should still not sort such override redirect windows on top if they are behind the guard window, as that'd result in windows hidden behind it now getting restacked anyway. Fix this by only sorting the override redirect windows that are found above the guard window on top. This fixes the override-redirect stacking test.
2018-07-12 08:18:54 +00:00
static gboolean
meta_stack_tracker_is_guard_window (MetaStackTracker *tracker,
uint64_t stack_id)
{
MetaX11Display *x11_display = tracker->display->x11_display;
if (!x11_display)
return FALSE;
return stack_id == x11_display->guard_window;
}
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
/**
* meta_stack_tracker_get_stack:
* @tracker: a #MetaStackTracker
* @windows: location to store list of windows, or %NULL
* @n_windows: location to store count of windows, or %NULL
*
Fix gobs of gtk-doc warnings https://bugzilla.gnome.org/show_bug.cgi?id=676856
2013-02-15 18:42:08 +00:00
* @windows will contain the most current view we have of the stacking order
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
* of the children of the root window. The returned array contains
* everything: InputOnly windows, override-redirect windows,
* hidden windows, etc. Some of these will correspond to MetaWindow
* objects, others won't.
*
* Assuming that no other clients have made requests that change
* the stacking order since we last received a notification, the
* returned list of windows is exactly that you'd get as the
* children when calling XQueryTree() on the root window.
*/
void
meta_stack_tracker_get_stack (MetaStackTracker *tracker,
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
guint64 **windows,
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
int *n_windows)
{
GArray *stack;
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
if (tracker->unverified_predictions->length == 0)
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
{
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
stack = tracker->verified_stack;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
}
else
{
if (tracker->predicted_stack == NULL)
{
GList *l;
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
tracker->predicted_stack = copy_stack (tracker->verified_stack);
for (l = tracker->unverified_predictions->head; l; l = l->next)
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
{
MetaStackOp *op = l->data;
MetaStackTracker: eliminate the resynchronization process The step where we requery the stacking order from the server than combine it in an arbitrary fashion with Wayland windows can be eliminated by observing that we are the final authority for Wayland window stacking - so if we apply each X event that we receive from the X server to our stack in a way that leaves the X windows ordered in the same way as on the server, and apply events that we have stored locally in a way that doesn't affect the ordering of X windows, than we have a fully correct ordering of windows. Ordering this in the order of first applying the X event and then applying the local portion also means that as long as we had an up-to-date view of the X stack the composite operation will be identical to what was requested. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 17:41:27 +00:00
meta_stack_op_apply (tracker, op, tracker->predicted_stack, APPLY_DEFAULT);
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
}
}
stack = tracker->predicted_stack;
}
if (windows)
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
*windows = (guint64 *)stack->data;
Add better tracking of real stacking order Wedging override-redirect windows into the constraint code in stack.c results in Mutter getting confused about the stacking order of these windows with respect to other windows, and may also in some cases cause Mutter to restack override-redirect windows. core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine events received from the X server with local changes we have made to come up with the best possible idea of what the stacking order is at any one point in time. core/screen.c core/screen-private.h: Create a MetaStackTracker for the screen. core/display.c: Feed relevant events to MetaStackTracker core/frame.c core/screen.c core/stack.c: When we make changes to the stacking order or add windows, record those changes immediatley in MetaStackTracker so we have the information without waiting for a round-trip. include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value for the X request serial used to create the window. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-13 20:45:32 +00:00
if (n_windows)
*n_windows = stack->len;
}
Move compositor-stack handling to MetaStackTracker In order to properly track the stacking order for override-redirect windows, move meta_compositor_sync_stack() call into MetaStackTracker. In the new location, we sync the stack as a before-redraw idle function, rather then using the freeze-thaw facilities of MetaStack. This is simpler, and also properly compresses multiple stack changes on notifications received from the X server. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-14 12:04:28 +00:00
/**
* meta_stack_tracker_sync_stack:
* @tracker: a #MetaStackTracker
*
* Informs the compositor of the current stacking order of windows,
* based on the predicted view maintained by the #MetaStackTracker.
*/
void
meta_stack_tracker_sync_stack (MetaStackTracker *tracker)
{
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
guint64 *windows;
Move compositor-stack handling to MetaStackTracker In order to properly track the stacking order for override-redirect windows, move meta_compositor_sync_stack() call into MetaStackTracker. In the new location, we sync the stack as a before-redraw idle function, rather then using the freeze-thaw facilities of MetaStack. This is simpler, and also properly compresses multiple stack changes on notifications received from the X server. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-14 12:04:28 +00:00
GList *meta_windows;
int n_windows;
int i;
Use "later functions" to fix priority problems with Clutter redraw There was a problem where if, for example, a restack was triggered out of a clutter event handler, then after Clutter processed the events, it would proceed immmediately on to repaint the stage without ever returning control to the GLib main loop. So even though we had an idle handler installed with a higher priority than the Clutter stage repainting the clutter stage repainting would happen first and we'd get a wrong frame. Fix this by introducing the idea of "later functions", which abstract the idea of "doing something later" away from g_idle_add() and use a combination of GLib idle functions and Clutter "repaint functions" to get our callbacks triggered at the right time, even when they are installed from a clutter event handler. https://bugzilla.gnome.org/show_bug.cgi?id=596334 This also resolve a FIXME where MUTTER_PRIORITY_BEFORE_REDRAW could starve stage repainting.
2009-09-25 19:47:22 +00:00
if (tracker->sync_stack_later)
Move compositor-stack handling to MetaStackTracker In order to properly track the stacking order for override-redirect windows, move meta_compositor_sync_stack() call into MetaStackTracker. In the new location, we sync the stack as a before-redraw idle function, rather then using the freeze-thaw facilities of MetaStack. This is simpler, and also properly compresses multiple stack changes on notifications received from the X server. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-14 12:04:28 +00:00
{
Use "later functions" to fix priority problems with Clutter redraw There was a problem where if, for example, a restack was triggered out of a clutter event handler, then after Clutter processed the events, it would proceed immmediately on to repaint the stage without ever returning control to the GLib main loop. So even though we had an idle handler installed with a higher priority than the Clutter stage repainting the clutter stage repainting would happen first and we'd get a wrong frame. Fix this by introducing the idea of "later functions", which abstract the idea of "doing something later" away from g_idle_add() and use a combination of GLib idle functions and Clutter "repaint functions" to get our callbacks triggered at the right time, even when they are installed from a clutter event handler. https://bugzilla.gnome.org/show_bug.cgi?id=596334 This also resolve a FIXME where MUTTER_PRIORITY_BEFORE_REDRAW could starve stage repainting.
2009-09-25 19:47:22 +00:00
meta_later_remove (tracker->sync_stack_later);
tracker->sync_stack_later = 0;
Move compositor-stack handling to MetaStackTracker In order to properly track the stacking order for override-redirect windows, move meta_compositor_sync_stack() call into MetaStackTracker. In the new location, we sync the stack as a before-redraw idle function, rather then using the freeze-thaw facilities of MetaStack. This is simpler, and also properly compresses multiple stack changes on notifications received from the X server. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-14 12:04:28 +00:00
}
stack-tracker: Keep override redirect windows on top Since commit 6b5cf2e, we keep override redirect windows on a layer above regular windows in the clutter actor scene graph. In the X server, and thus for input purposes, these windows might end up being stacked below regular windows though, e.g. because a new regular window is mapped after an OR window. Fix this disconnect by re-stacking OR windows on top when syncing the window stack with the compositor. https://bugzilla.gnome.org/show_bug.cgi?id=780485
2017-05-19 15:11:19 +00:00
meta_stack_tracker_keep_override_redirect_on_top (tracker);
Move compositor-stack handling to MetaStackTracker In order to properly track the stacking order for override-redirect windows, move meta_compositor_sync_stack() call into MetaStackTracker. In the new location, we sync the stack as a before-redraw idle function, rather then using the freeze-thaw facilities of MetaStack. This is simpler, and also properly compresses multiple stack changes on notifications received from the X server. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-14 12:04:28 +00:00
meta_stack_tracker_get_stack (tracker, &windows, &n_windows);
meta_windows = NULL;
for (i = 0; i < n_windows; i++)
{
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
guint64 window = windows[i];
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
if (META_STACK_ID_IS_X11 (window))
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
{
Move stack tracking and guard_window outside of MetaScreen Move stack, stack_tracker to MetaDisplay guard_window to MetaX11Display https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 17:03:51 +00:00
MetaX11Display *x11_display = tracker->display->x11_display;
core: Check X11 display availability before use in MetaStackTracker This object can be generally triggered without a X11 display, so make sure this is alright. For guard window checks, use our internal meta_stack_tracker_is_guard_window() call, which is already no-x11 aware. https://gitlab.gnome.org/GNOME/mutter/merge_requests/730
2019-08-15 22:27:03 +00:00
MetaWindow *meta_window = NULL;
if (x11_display)
meta_window = meta_x11_display_lookup_x_window (x11_display, (Window) window);
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
/* When mapping back from xwindow to MetaWindow we have to be a bit careful;
* children of the root could include unmapped windows created by toolkits
* for internal purposes, including ones that we have registered in our
* XID => window table. (Wine uses a toplevel for _NET_WM_USER_TIME_WINDOW;
* see window-prop.c:reload_net_wm_user_time_window() for registration.)
*/
if (meta_window &&
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
((Window)window == meta_window->xwindow ||
(meta_window->frame && (Window)window == meta_window->frame->xwindow)))
Add support for stacking X and Wayland windows together This breaks down the assumptions in stack-tracker.c and stack.c that Mutter is only stacking X windows. The stack tracker now tracks windows using a MetaStackWindow structure which is a union with a type member so that X windows can be distinguished from Wayland windows. Some notable changes are: Queued stack tracker operations that affect Wayland windows will not be associated with an X serial number. If an operation only affects a Wayland window and there are no queued stack tracker operations ("unvalidated predictions") then the operation is applied immediately since there is no server involved with changing the stacking for Wayland windows. The stack tracker can no longer respond to X events by turning them into stack operations and discarding the predicted operations made prior to that event because operations based on X events don't know anything about the stacking of Wayland windows. Instead of discarding old predictions the new approach is to trust the predictions but whenever we receive an event from the server that affects stacking we cross-reference with the predicted stack and check for consistency. So e.g. if we have an event that says ADD window A then we apply the predictions (up to the serial for that event) and verify the predicted state includes a window A. Similarly if an event says RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for that event) and verify that window B is above C. If we ever receive spurious stacking events (with a serial older than we would expect) or find an inconsistency (some things aren't possible to predict from the compositor) then we hit a re-synchronization code-path that will query the X server for the full stacking order and then use that stack to walk through our combined stack and force the X windows to match the just queried stack but avoiding disrupting the relative stacking of Wayland windows. This will be relatively expensive but shouldn't be hit for compositor initiated restacking operations where our predictions should be accurate. The code in core/stack.c that deals with synchronizing the window stack with the X server had to be updated quite heavily. In general the patch avoids changing the fundamental approach being used but most of the code did need some amount of re-factoring to consider what re-stacking operations actually involve X or not and when we need to restack X windows we sometimes need to search for a suitable X sibling to restack relative too since the closest siblings may be Wayland windows.
2012-04-05 10:22:13 +00:00
meta_windows = g_list_prepend (meta_windows, meta_window);
}
else
Replace MetaStackWindow with a 64-bit "stack ID" Putting X windows and pointers to MetaWindows into a union had a number of problems: - It caused awkward initialization and conditionalization - There was no way to refer to Wayland windows (represented by MetaWindow *) in the past, which is necessary for the MetaStackTracker algorithms - We never even cleaned up old MetaStackWindow so there could be records in MetaStackWindow pointing to freed MetaWindow. Replace MetaStackWindow with a 64-bit "stack ID" which is: - The XID for X Windows - a "window stamp" for Wayland windows - window stamps are assigned for all MetaWindow and are unique across the life of the process. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 01:20:14 +00:00
meta_windows = g_list_prepend (meta_windows,
Move stack tracking and guard_window outside of MetaScreen Move stack, stack_tracker to MetaDisplay guard_window to MetaX11Display https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 17:03:51 +00:00
meta_display_lookup_stamp (tracker->display, window));
Move compositor-stack handling to MetaStackTracker In order to properly track the stacking order for override-redirect windows, move meta_compositor_sync_stack() call into MetaStackTracker. In the new location, we sync the stack as a before-redraw idle function, rather then using the freeze-thaw facilities of MetaStack. This is simpler, and also properly compresses multiple stack changes on notifications received from the X server. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-14 12:04:28 +00:00
}
Move stack tracking and guard_window outside of MetaScreen Move stack, stack_tracker to MetaDisplay guard_window to MetaX11Display https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 17:03:51 +00:00
meta_compositor_sync_stack (tracker->display->compositor,
Assume the compositor always exists At one point, it was supported to run mutter without a compositor, but we don't allow that any longer. A lot of code already assumes display->compositor exists and doesn't check for a NULL pointer, so just kill the rest of the checks.
2014-03-18 21:06:42 +00:00
meta_windows);
Move compositor-stack handling to MetaStackTracker In order to properly track the stacking order for override-redirect windows, move meta_compositor_sync_stack() call into MetaStackTracker. In the new location, we sync the stack as a before-redraw idle function, rather then using the freeze-thaw facilities of MetaStack. This is simpler, and also properly compresses multiple stack changes on notifications received from the X server. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-14 12:04:28 +00:00
g_list_free (meta_windows);
Move stack tracking and guard_window outside of MetaScreen Move stack, stack_tracker to MetaDisplay guard_window to MetaX11Display https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 17:03:51 +00:00
meta_display_restacked (tracker->display);
Move compositor-stack handling to MetaStackTracker In order to properly track the stacking order for override-redirect windows, move meta_compositor_sync_stack() call into MetaStackTracker. In the new location, we sync the stack as a before-redraw idle function, rather then using the freeze-thaw facilities of MetaStack. This is simpler, and also properly compresses multiple stack changes on notifications received from the X server. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-14 12:04:28 +00:00
}
static gboolean
Use "later functions" to fix priority problems with Clutter redraw There was a problem where if, for example, a restack was triggered out of a clutter event handler, then after Clutter processed the events, it would proceed immmediately on to repaint the stage without ever returning control to the GLib main loop. So even though we had an idle handler installed with a higher priority than the Clutter stage repainting the clutter stage repainting would happen first and we'd get a wrong frame. Fix this by introducing the idea of "later functions", which abstract the idea of "doing something later" away from g_idle_add() and use a combination of GLib idle functions and Clutter "repaint functions" to get our callbacks triggered at the right time, even when they are installed from a clutter event handler. https://bugzilla.gnome.org/show_bug.cgi?id=596334 This also resolve a FIXME where MUTTER_PRIORITY_BEFORE_REDRAW could starve stage repainting.
2009-09-25 19:47:22 +00:00
stack_tracker_sync_stack_later (gpointer data)
Move compositor-stack handling to MetaStackTracker In order to properly track the stacking order for override-redirect windows, move meta_compositor_sync_stack() call into MetaStackTracker. In the new location, we sync the stack as a before-redraw idle function, rather then using the freeze-thaw facilities of MetaStack. This is simpler, and also properly compresses multiple stack changes on notifications received from the X server. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-14 12:04:28 +00:00
{
meta_stack_tracker_sync_stack (data);
return FALSE;
}
/**
* meta_stack_tracker_queue_sync_stack:
* @tracker: a #MetaStackTracker
*
* Queue informing the compositor of the new stacking order before the
* next redraw. (See meta_stack_tracker_sync_stack()). This is called
* internally when the stack of X windows changes, but also needs be
* called directly when we an undecorated window is first shown or
* withdrawn since the compositor's stacking order (which contains only
* the windows that have a corresponding MetaWindow) will change without
* any change to the stacking order of the X windows, if we are creating
* or destroying MetaWindows.
*/
void
meta_stack_tracker_queue_sync_stack (MetaStackTracker *tracker)
{
Use "later functions" to fix priority problems with Clutter redraw There was a problem where if, for example, a restack was triggered out of a clutter event handler, then after Clutter processed the events, it would proceed immmediately on to repaint the stage without ever returning control to the GLib main loop. So even though we had an idle handler installed with a higher priority than the Clutter stage repainting the clutter stage repainting would happen first and we'd get a wrong frame. Fix this by introducing the idea of "later functions", which abstract the idea of "doing something later" away from g_idle_add() and use a combination of GLib idle functions and Clutter "repaint functions" to get our callbacks triggered at the right time, even when they are installed from a clutter event handler. https://bugzilla.gnome.org/show_bug.cgi?id=596334 This also resolve a FIXME where MUTTER_PRIORITY_BEFORE_REDRAW could starve stage repainting.
2009-09-25 19:47:22 +00:00
if (tracker->sync_stack_later == 0)
Move compositor-stack handling to MetaStackTracker In order to properly track the stacking order for override-redirect windows, move meta_compositor_sync_stack() call into MetaStackTracker. In the new location, we sync the stack as a before-redraw idle function, rather then using the freeze-thaw facilities of MetaStack. This is simpler, and also properly compresses multiple stack changes on notifications received from the X server. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-14 12:04:28 +00:00
{
MetaScreen: Add tracking of whether there are fullscreen windows Trying to track the fullscreen status outside of Mutter, as GNOME Shell was doing previously, was very prone to errors, because Mutter has a very tricky definition of when a window is set to be fullscreen and *actually* acting like a fullscreen window. * Add meta_screen_get_monitor_in_fullscreen() and an ::in-fullscreen-changed signal. This allows an application to track when there are fullscreen windows on a monitor. * Do the computation of fullscreen status in a "later" function that runs after showing, so we properly take focus into account. * To get ordering of different phases right, add more values to MetaLaterType. * Add auto-minimization, similar to what was added to GNOME Shell earlier in this cycle - if a window is set to be fullscreen, but not actually fullscreen, minimize. https://bugzilla.gnome.org/show_bug.cgi?id=649748
2013-03-14 20:55:49 +00:00
tracker->sync_stack_later = meta_later_add (META_LATER_SYNC_STACK,
Use "later functions" to fix priority problems with Clutter redraw There was a problem where if, for example, a restack was triggered out of a clutter event handler, then after Clutter processed the events, it would proceed immmediately on to repaint the stage without ever returning control to the GLib main loop. So even though we had an idle handler installed with a higher priority than the Clutter stage repainting the clutter stage repainting would happen first and we'd get a wrong frame. Fix this by introducing the idea of "later functions", which abstract the idea of "doing something later" away from g_idle_add() and use a combination of GLib idle functions and Clutter "repaint functions" to get our callbacks triggered at the right time, even when they are installed from a clutter event handler. https://bugzilla.gnome.org/show_bug.cgi?id=596334 This also resolve a FIXME where MUTTER_PRIORITY_BEFORE_REDRAW could starve stage repainting.
2009-09-25 19:47:22 +00:00
stack_tracker_sync_stack_later,
Move compositor-stack handling to MetaStackTracker In order to properly track the stacking order for override-redirect windows, move meta_compositor_sync_stack() call into MetaStackTracker. In the new location, we sync the stack as a before-redraw idle function, rather then using the freeze-thaw facilities of MetaStack. This is simpler, and also properly compresses multiple stack changes on notifications received from the X server. http://bugzilla.gnome.org/show_bug.cgi?id=585984
2009-06-14 12:04:28 +00:00
tracker, NULL);
}
}
Move manipulation of the X stack to MetaStackTracker Since MetaStackTracker is the code that knows about the current X stacking order and the relationship between X windows and Wayland windows, it's cleaner to encapsulate stack manipulation in MetaStackTracker rather than have the calling code make the X calls and only call into MetaStackTracker to inform it about the changes. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 19:44:26 +00:00
/* When moving an X window we sometimes need an X based sibling.
*
* If the given sibling is X based this function returns it back
* otherwise it searches downwards looking for the nearest X window.
*
* If no X based sibling could be found return NULL. */
static Window
find_x11_sibling_downwards (MetaStackTracker *tracker,
guint64 sibling)
{
guint64 *windows;
int n_windows;
int i;
if (META_STACK_ID_IS_X11 (sibling))
return (Window)sibling;
meta_stack_tracker_get_stack (tracker,
&windows, &n_windows);
/* NB: Children are in order from bottom to top and we
* want to search downwards for the nearest X window.
*/
for (i = n_windows - 1; i >= 0; i--)
if (windows[i] == sibling)
break;
for (; i >= 0; i--)
{
if (META_STACK_ID_IS_X11 (windows[i]))
return (Window)windows[i];
}
return None;
}
static Window
find_x11_sibling_upwards (MetaStackTracker *tracker,
guint64 sibling)
{
guint64 *windows;
int n_windows;
int i;
if (META_STACK_ID_IS_X11 (sibling))
return (Window)sibling;
meta_stack_tracker_get_stack (tracker,
&windows, &n_windows);
for (i = 0; i < n_windows; i++)
if (windows[i] == sibling)
break;
for (; i < n_windows; i++)
{
if (META_STACK_ID_IS_X11 (windows[i]))
return (Window)windows[i];
}
return None;
}
stack-tracker: Make lower_below / raise_above internal as well These are unused elsewhere.
2014-09-12 22:56:27 +00:00
static void
Move manipulation of the X stack to MetaStackTracker Since MetaStackTracker is the code that knows about the current X stacking order and the relationship between X windows and Wayland windows, it's cleaner to encapsulate stack manipulation in MetaStackTracker rather than have the calling code make the X calls and only call into MetaStackTracker to inform it about the changes. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 19:44:26 +00:00
meta_stack_tracker_lower_below (MetaStackTracker *tracker,
guint64 window,
guint64 sibling)
{
gulong serial = 0;
Move stack tracking and guard_window outside of MetaScreen Move stack, stack_tracker to MetaDisplay guard_window to MetaX11Display https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 17:03:51 +00:00
MetaX11Display *x11_display = tracker->display->x11_display;
Move manipulation of the X stack to MetaStackTracker Since MetaStackTracker is the code that knows about the current X stacking order and the relationship between X windows and Wayland windows, it's cleaner to encapsulate stack manipulation in MetaStackTracker rather than have the calling code make the X calls and only call into MetaStackTracker to inform it about the changes. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 19:44:26 +00:00
if (META_STACK_ID_IS_X11 (window))
{
XWindowChanges changes;
MetaStackTracker: optimize out unnecessary X restacking We have a quite accurate view of the X stack, so there's no good reason to ask the X server to do restacking that has no effect. (Restackings that have no effect on either X windows or Wayland windows were generally optimized out in the synchronization code, but in other cases like moving an X window that is only beneath Wayland windows to the top of the stack we would make such requests.) Removing such requests: - Is a small efficiency win in itself - Allows us to immediately go ahead and apply Wayland changes to the verified stack - Prevents queued Wayland changes piling up waiting for an X event that will never be received, since the X server will not send confirmation of no-op restacks. Since such operations may still have an effect on the relative stacking of X and Wayland windows, we need to continue applying them to the local stack. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-10 17:06:28 +00:00
changes.sibling = sibling ? find_x11_sibling_upwards (tracker, sibling) : None;
Move manipulation of the X stack to MetaStackTracker Since MetaStackTracker is the code that knows about the current X stacking order and the relationship between X windows and Wayland windows, it's cleaner to encapsulate stack manipulation in MetaStackTracker rather than have the calling code make the X calls and only call into MetaStackTracker to inform it about the changes. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 19:44:26 +00:00
MetaStackTracker: optimize out unnecessary X restacking We have a quite accurate view of the X stack, so there's no good reason to ask the X server to do restacking that has no effect. (Restackings that have no effect on either X windows or Wayland windows were generally optimized out in the synchronization code, but in other cases like moving an X window that is only beneath Wayland windows to the top of the stack we would make such requests.) Removing such requests: - Is a small efficiency win in itself - Allows us to immediately go ahead and apply Wayland changes to the verified stack - Prevents queued Wayland changes piling up waiting for an X event that will never be received, since the X server will not send confirmation of no-op restacks. Since such operations may still have an effect on the relative stacking of X and Wayland windows, we need to continue applying them to the local stack. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-10 17:06:28 +00:00
if (changes.sibling != find_x11_sibling_upwards (tracker, window))
{
Start populating MetaX11Display - Moved xdisplay, name and various atoms from MetaDisplay - Moved xroot, screen_name, default_depth and default_xvisual from MetaScreen - Moved some X11 specific functions from screen.c and display.c to meta-x11-display.c https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 16:26:30 +00:00
serial = XNextRequest (x11_display->xdisplay);
MetaStackTracker: optimize out unnecessary X restacking We have a quite accurate view of the X stack, so there's no good reason to ask the X server to do restacking that has no effect. (Restackings that have no effect on either X windows or Wayland windows were generally optimized out in the synchronization code, but in other cases like moving an X window that is only beneath Wayland windows to the top of the stack we would make such requests.) Removing such requests: - Is a small efficiency win in itself - Allows us to immediately go ahead and apply Wayland changes to the verified stack - Prevents queued Wayland changes piling up waiting for an X event that will never be received, since the X server will not send confirmation of no-op restacks. Since such operations may still have an effect on the relative stacking of X and Wayland windows, we need to continue applying them to the local stack. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-10 17:06:28 +00:00
Rename errors.[ch] to meta-x11-errors.[ch] Also rename meta_error_trap_* to meta_x11_error_trap_* and move meta-x11-errors.c to src/x11 https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-27 18:48:55 +00:00
meta_x11_error_trap_push (x11_display);
Move manipulation of the X stack to MetaStackTracker Since MetaStackTracker is the code that knows about the current X stacking order and the relationship between X windows and Wayland windows, it's cleaner to encapsulate stack manipulation in MetaStackTracker rather than have the calling code make the X calls and only call into MetaStackTracker to inform it about the changes. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 19:44:26 +00:00
MetaStackTracker: optimize out unnecessary X restacking We have a quite accurate view of the X stack, so there's no good reason to ask the X server to do restacking that has no effect. (Restackings that have no effect on either X windows or Wayland windows were generally optimized out in the synchronization code, but in other cases like moving an X window that is only beneath Wayland windows to the top of the stack we would make such requests.) Removing such requests: - Is a small efficiency win in itself - Allows us to immediately go ahead and apply Wayland changes to the verified stack - Prevents queued Wayland changes piling up waiting for an X event that will never be received, since the X server will not send confirmation of no-op restacks. Since such operations may still have an effect on the relative stacking of X and Wayland windows, we need to continue applying them to the local stack. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-10 17:06:28 +00:00
changes.stack_mode = changes.sibling ? Below : Above;
Move manipulation of the X stack to MetaStackTracker Since MetaStackTracker is the code that knows about the current X stacking order and the relationship between X windows and Wayland windows, it's cleaner to encapsulate stack manipulation in MetaStackTracker rather than have the calling code make the X calls and only call into MetaStackTracker to inform it about the changes. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 19:44:26 +00:00
Start populating MetaX11Display - Moved xdisplay, name and various atoms from MetaDisplay - Moved xroot, screen_name, default_depth and default_xvisual from MetaScreen - Moved some X11 specific functions from screen.c and display.c to meta-x11-display.c https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 16:26:30 +00:00
XConfigureWindow (x11_display->xdisplay,
MetaStackTracker: optimize out unnecessary X restacking We have a quite accurate view of the X stack, so there's no good reason to ask the X server to do restacking that has no effect. (Restackings that have no effect on either X windows or Wayland windows were generally optimized out in the synchronization code, but in other cases like moving an X window that is only beneath Wayland windows to the top of the stack we would make such requests.) Removing such requests: - Is a small efficiency win in itself - Allows us to immediately go ahead and apply Wayland changes to the verified stack - Prevents queued Wayland changes piling up waiting for an X event that will never be received, since the X server will not send confirmation of no-op restacks. Since such operations may still have an effect on the relative stacking of X and Wayland windows, we need to continue applying them to the local stack. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-10 17:06:28 +00:00
window,
(changes.sibling ? CWSibling : 0) | CWStackMode,
&changes);
Move manipulation of the X stack to MetaStackTracker Since MetaStackTracker is the code that knows about the current X stacking order and the relationship between X windows and Wayland windows, it's cleaner to encapsulate stack manipulation in MetaStackTracker rather than have the calling code make the X calls and only call into MetaStackTracker to inform it about the changes. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 19:44:26 +00:00
Rename errors.[ch] to meta-x11-errors.[ch] Also rename meta_error_trap_* to meta_x11_error_trap_* and move meta-x11-errors.c to src/x11 https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-27 18:48:55 +00:00
meta_x11_error_trap_pop (x11_display);
MetaStackTracker: optimize out unnecessary X restacking We have a quite accurate view of the X stack, so there's no good reason to ask the X server to do restacking that has no effect. (Restackings that have no effect on either X windows or Wayland windows were generally optimized out in the synchronization code, but in other cases like moving an X window that is only beneath Wayland windows to the top of the stack we would make such requests.) Removing such requests: - Is a small efficiency win in itself - Allows us to immediately go ahead and apply Wayland changes to the verified stack - Prevents queued Wayland changes piling up waiting for an X event that will never be received, since the X server will not send confirmation of no-op restacks. Since such operations may still have an effect on the relative stacking of X and Wayland windows, we need to continue applying them to the local stack. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-10 17:06:28 +00:00
}
Move manipulation of the X stack to MetaStackTracker Since MetaStackTracker is the code that knows about the current X stacking order and the relationship between X windows and Wayland windows, it's cleaner to encapsulate stack manipulation in MetaStackTracker rather than have the calling code make the X calls and only call into MetaStackTracker to inform it about the changes. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 19:44:26 +00:00
}
meta_stack_tracker_record_lower_below (tracker,
window, sibling,
serial);
}
stack-tracker: Make lower_below / raise_above internal as well These are unused elsewhere.
2014-09-12 22:56:27 +00:00
static void
Move manipulation of the X stack to MetaStackTracker Since MetaStackTracker is the code that knows about the current X stacking order and the relationship between X windows and Wayland windows, it's cleaner to encapsulate stack manipulation in MetaStackTracker rather than have the calling code make the X calls and only call into MetaStackTracker to inform it about the changes. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 19:44:26 +00:00
meta_stack_tracker_raise_above (MetaStackTracker *tracker,
guint64 window,
guint64 sibling)
{
gulong serial = 0;
Move stack tracking and guard_window outside of MetaScreen Move stack, stack_tracker to MetaDisplay guard_window to MetaX11Display https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 17:03:51 +00:00
MetaX11Display *x11_display = tracker->display->x11_display;
Move manipulation of the X stack to MetaStackTracker Since MetaStackTracker is the code that knows about the current X stacking order and the relationship between X windows and Wayland windows, it's cleaner to encapsulate stack manipulation in MetaStackTracker rather than have the calling code make the X calls and only call into MetaStackTracker to inform it about the changes. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 19:44:26 +00:00
if (META_STACK_ID_IS_X11 (window))
{
XWindowChanges changes;
MetaStackTracker: optimize out unnecessary X restacking We have a quite accurate view of the X stack, so there's no good reason to ask the X server to do restacking that has no effect. (Restackings that have no effect on either X windows or Wayland windows were generally optimized out in the synchronization code, but in other cases like moving an X window that is only beneath Wayland windows to the top of the stack we would make such requests.) Removing such requests: - Is a small efficiency win in itself - Allows us to immediately go ahead and apply Wayland changes to the verified stack - Prevents queued Wayland changes piling up waiting for an X event that will never be received, since the X server will not send confirmation of no-op restacks. Since such operations may still have an effect on the relative stacking of X and Wayland windows, we need to continue applying them to the local stack. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-10 17:06:28 +00:00
changes.sibling = sibling ? find_x11_sibling_downwards (tracker, sibling) : None;
Move manipulation of the X stack to MetaStackTracker Since MetaStackTracker is the code that knows about the current X stacking order and the relationship between X windows and Wayland windows, it's cleaner to encapsulate stack manipulation in MetaStackTracker rather than have the calling code make the X calls and only call into MetaStackTracker to inform it about the changes. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 19:44:26 +00:00
MetaStackTracker: optimize out unnecessary X restacking We have a quite accurate view of the X stack, so there's no good reason to ask the X server to do restacking that has no effect. (Restackings that have no effect on either X windows or Wayland windows were generally optimized out in the synchronization code, but in other cases like moving an X window that is only beneath Wayland windows to the top of the stack we would make such requests.) Removing such requests: - Is a small efficiency win in itself - Allows us to immediately go ahead and apply Wayland changes to the verified stack - Prevents queued Wayland changes piling up waiting for an X event that will never be received, since the X server will not send confirmation of no-op restacks. Since such operations may still have an effect on the relative stacking of X and Wayland windows, we need to continue applying them to the local stack. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-10 17:06:28 +00:00
if (changes.sibling != find_x11_sibling_downwards (tracker, window))
{
Start populating MetaX11Display - Moved xdisplay, name and various atoms from MetaDisplay - Moved xroot, screen_name, default_depth and default_xvisual from MetaScreen - Moved some X11 specific functions from screen.c and display.c to meta-x11-display.c https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 16:26:30 +00:00
serial = XNextRequest (x11_display->xdisplay);
Move manipulation of the X stack to MetaStackTracker Since MetaStackTracker is the code that knows about the current X stacking order and the relationship between X windows and Wayland windows, it's cleaner to encapsulate stack manipulation in MetaStackTracker rather than have the calling code make the X calls and only call into MetaStackTracker to inform it about the changes. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 19:44:26 +00:00
Rename errors.[ch] to meta-x11-errors.[ch] Also rename meta_error_trap_* to meta_x11_error_trap_* and move meta-x11-errors.c to src/x11 https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-27 18:48:55 +00:00
meta_x11_error_trap_push (x11_display);
Move manipulation of the X stack to MetaStackTracker Since MetaStackTracker is the code that knows about the current X stacking order and the relationship between X windows and Wayland windows, it's cleaner to encapsulate stack manipulation in MetaStackTracker rather than have the calling code make the X calls and only call into MetaStackTracker to inform it about the changes. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 19:44:26 +00:00
MetaStackTracker: optimize out unnecessary X restacking We have a quite accurate view of the X stack, so there's no good reason to ask the X server to do restacking that has no effect. (Restackings that have no effect on either X windows or Wayland windows were generally optimized out in the synchronization code, but in other cases like moving an X window that is only beneath Wayland windows to the top of the stack we would make such requests.) Removing such requests: - Is a small efficiency win in itself - Allows us to immediately go ahead and apply Wayland changes to the verified stack - Prevents queued Wayland changes piling up waiting for an X event that will never be received, since the X server will not send confirmation of no-op restacks. Since such operations may still have an effect on the relative stacking of X and Wayland windows, we need to continue applying them to the local stack. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-10 17:06:28 +00:00
changes.stack_mode = changes.sibling ? Above : Below;
Move manipulation of the X stack to MetaStackTracker Since MetaStackTracker is the code that knows about the current X stacking order and the relationship between X windows and Wayland windows, it's cleaner to encapsulate stack manipulation in MetaStackTracker rather than have the calling code make the X calls and only call into MetaStackTracker to inform it about the changes. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 19:44:26 +00:00
Start populating MetaX11Display - Moved xdisplay, name and various atoms from MetaDisplay - Moved xroot, screen_name, default_depth and default_xvisual from MetaScreen - Moved some X11 specific functions from screen.c and display.c to meta-x11-display.c https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 16:26:30 +00:00
XConfigureWindow (x11_display->xdisplay,
MetaStackTracker: optimize out unnecessary X restacking We have a quite accurate view of the X stack, so there's no good reason to ask the X server to do restacking that has no effect. (Restackings that have no effect on either X windows or Wayland windows were generally optimized out in the synchronization code, but in other cases like moving an X window that is only beneath Wayland windows to the top of the stack we would make such requests.) Removing such requests: - Is a small efficiency win in itself - Allows us to immediately go ahead and apply Wayland changes to the verified stack - Prevents queued Wayland changes piling up waiting for an X event that will never be received, since the X server will not send confirmation of no-op restacks. Since such operations may still have an effect on the relative stacking of X and Wayland windows, we need to continue applying them to the local stack. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-10 17:06:28 +00:00
(Window)window,
(changes.sibling ? CWSibling : 0) | CWStackMode,
&changes);
Rename errors.[ch] to meta-x11-errors.[ch] Also rename meta_error_trap_* to meta_x11_error_trap_* and move meta-x11-errors.c to src/x11 https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-27 18:48:55 +00:00
meta_x11_error_trap_pop (x11_display);
MetaStackTracker: optimize out unnecessary X restacking We have a quite accurate view of the X stack, so there's no good reason to ask the X server to do restacking that has no effect. (Restackings that have no effect on either X windows or Wayland windows were generally optimized out in the synchronization code, but in other cases like moving an X window that is only beneath Wayland windows to the top of the stack we would make such requests.) Removing such requests: - Is a small efficiency win in itself - Allows us to immediately go ahead and apply Wayland changes to the verified stack - Prevents queued Wayland changes piling up waiting for an X event that will never be received, since the X server will not send confirmation of no-op restacks. Since such operations may still have an effect on the relative stacking of X and Wayland windows, we need to continue applying them to the local stack. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-10 17:06:28 +00:00
}
Move manipulation of the X stack to MetaStackTracker Since MetaStackTracker is the code that knows about the current X stacking order and the relationship between X windows and Wayland windows, it's cleaner to encapsulate stack manipulation in MetaStackTracker rather than have the calling code make the X calls and only call into MetaStackTracker to inform it about the changes. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 19:44:26 +00:00
}
meta_stack_tracker_record_raise_above (tracker, window,
sibling, serial);
}
stack-tracker: Make lower_below / raise_above internal as well These are unused elsewhere.
2014-09-12 22:56:27 +00:00
void
meta_stack_tracker_lower (MetaStackTracker *tracker,
guint64 window)
{
meta_stack_tracker_raise_above (tracker, window, None);
}
stack-tracker: Keep override redirect windows on top Since commit 6b5cf2e, we keep override redirect windows on a layer above regular windows in the clutter actor scene graph. In the X server, and thus for input purposes, these windows might end up being stacked below regular windows though, e.g. because a new regular window is mapped after an OR window. Fix this disconnect by re-stacking OR windows on top when syncing the window stack with the compositor. https://bugzilla.gnome.org/show_bug.cgi?id=780485
2017-05-19 15:11:19 +00:00
static void
meta_stack_tracker_keep_override_redirect_on_top (MetaStackTracker *tracker)
{
guint64 *stack;
int n_windows, i;
int topmost_non_or;
meta_stack_tracker_get_stack (tracker, &stack, &n_windows);
for (i = n_windows - 1; i >= 0; i--)
{
stack-tracker: Don't sort O-R's under guard window on top As of "stack-tracker: Keep override redirect windows on top" (e3d5bc077d0ee5dc0368f99d22ce352c696644b9), we always sorted all override redirect on top of regular windows, as so is expected by regular override redirect windows. This had an unwanted consequence, however, which is that we should still not sort such override redirect windows on top if they are behind the guard window, as that'd result in windows hidden behind it now getting restacked anyway. Fix this by only sorting the override redirect windows that are found above the guard window on top. This fixes the override-redirect stacking test.
2018-07-12 08:18:54 +00:00
MetaWindow *window;
Move stack tracking and guard_window outside of MetaScreen Move stack, stack_tracker to MetaDisplay guard_window to MetaX11Display https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 17:03:51 +00:00
window = meta_display_lookup_stack_id (tracker->display, stack[i]);
stack-tracker: Keep override redirect windows on top Since commit 6b5cf2e, we keep override redirect windows on a layer above regular windows in the clutter actor scene graph. In the X server, and thus for input purposes, these windows might end up being stacked below regular windows though, e.g. because a new regular window is mapped after an OR window. Fix this disconnect by re-stacking OR windows on top when syncing the window stack with the compositor. https://bugzilla.gnome.org/show_bug.cgi?id=780485
2017-05-19 15:11:19 +00:00
if (window && window->layer != META_LAYER_OVERRIDE_REDIRECT)
break;
}
topmost_non_or = i;
for (i -= 1; i >= 0; i--)
{
stack-tracker: Don't sort O-R's under guard window on top As of "stack-tracker: Keep override redirect windows on top" (e3d5bc077d0ee5dc0368f99d22ce352c696644b9), we always sorted all override redirect on top of regular windows, as so is expected by regular override redirect windows. This had an unwanted consequence, however, which is that we should still not sort such override redirect windows on top if they are behind the guard window, as that'd result in windows hidden behind it now getting restacked anyway. Fix this by only sorting the override redirect windows that are found above the guard window on top. This fixes the override-redirect stacking test.
2018-07-12 08:18:54 +00:00
MetaWindow *window;
if (meta_stack_tracker_is_guard_window (tracker, stack[i]))
break;
Move stack tracking and guard_window outside of MetaScreen Move stack, stack_tracker to MetaDisplay guard_window to MetaX11Display https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 17:03:51 +00:00
window = meta_display_lookup_stack_id (tracker->display, stack[i]);
stack-tracker: Keep override redirect windows on top Since commit 6b5cf2e, we keep override redirect windows on a layer above regular windows in the clutter actor scene graph. In the X server, and thus for input purposes, these windows might end up being stacked below regular windows though, e.g. because a new regular window is mapped after an OR window. Fix this disconnect by re-stacking OR windows on top when syncing the window stack with the compositor. https://bugzilla.gnome.org/show_bug.cgi?id=780485
2017-05-19 15:11:19 +00:00
if (window && window->layer == META_LAYER_OVERRIDE_REDIRECT)
{
meta_stack_tracker_raise_above (tracker, stack[i], stack[topmost_non_or]);
meta_stack_tracker_get_stack (tracker, &stack, &n_windows);
topmost_non_or -= 1;
}
}
}
Move manipulation of the X stack to MetaStackTracker Since MetaStackTracker is the code that knows about the current X stacking order and the relationship between X windows and Wayland windows, it's cleaner to encapsulate stack manipulation in MetaStackTracker rather than have the calling code make the X calls and only call into MetaStackTracker to inform it about the changes. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 19:44:26 +00:00
void
Move logic for syncing the stack to the X server into MetaStackTracker stack.c:sync_stack_to_xserver had both code for assembling the desired stack, and code for enforcing the desired stack on the actual stack of X and Wayland windows; the latter part is properly the domain of stack-tracker.c; moving the code to apply the stack there both simplifies it and keeps stack.c more manageable. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-10 15:58:42 +00:00
meta_stack_tracker_restack_managed (MetaStackTracker *tracker,
const guint64 *managed,
int n_managed)
Move manipulation of the X stack to MetaStackTracker Since MetaStackTracker is the code that knows about the current X stacking order and the relationship between X windows and Wayland windows, it's cleaner to encapsulate stack manipulation in MetaStackTracker rather than have the calling code make the X calls and only call into MetaStackTracker to inform it about the changes. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 19:44:26 +00:00
{
Move logic for syncing the stack to the X server into MetaStackTracker stack.c:sync_stack_to_xserver had both code for assembling the desired stack, and code for enforcing the desired stack on the actual stack of X and Wayland windows; the latter part is properly the domain of stack-tracker.c; moving the code to apply the stack there both simplifies it and keeps stack.c more manageable. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-10 15:58:42 +00:00
guint64 *windows;
int n_windows;
int old_pos, new_pos;
Move manipulation of the X stack to MetaStackTracker Since MetaStackTracker is the code that knows about the current X stacking order and the relationship between X windows and Wayland windows, it's cleaner to encapsulate stack manipulation in MetaStackTracker rather than have the calling code make the X calls and only call into MetaStackTracker to inform it about the changes. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 19:44:26 +00:00
Move logic for syncing the stack to the X server into MetaStackTracker stack.c:sync_stack_to_xserver had both code for assembling the desired stack, and code for enforcing the desired stack on the actual stack of X and Wayland windows; the latter part is properly the domain of stack-tracker.c; moving the code to apply the stack there both simplifies it and keeps stack.c more manageable. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-10 15:58:42 +00:00
if (n_managed == 0)
return;
meta_stack_tracker_get_stack (tracker, &windows, &n_windows);
/* If the top window has to be restacked, we don't want to move it to the very
* top of the stack, since apps expect override-redirect windows to stay near
* the top of the X stack; we instead move it above all managed windows (or
* above the guard window if there are no non-hidden managed windows.)
Move manipulation of the X stack to MetaStackTracker Since MetaStackTracker is the code that knows about the current X stacking order and the relationship between X windows and Wayland windows, it's cleaner to encapsulate stack manipulation in MetaStackTracker rather than have the calling code make the X calls and only call into MetaStackTracker to inform it about the changes. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 19:44:26 +00:00
*/
Move logic for syncing the stack to the X server into MetaStackTracker stack.c:sync_stack_to_xserver had both code for assembling the desired stack, and code for enforcing the desired stack on the actual stack of X and Wayland windows; the latter part is properly the domain of stack-tracker.c; moving the code to apply the stack there both simplifies it and keeps stack.c more manageable. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-10 15:58:42 +00:00
old_pos = n_windows - 1;
for (old_pos = n_windows - 1; old_pos >= 0; old_pos--)
{
Move stack tracking and guard_window outside of MetaScreen Move stack, stack_tracker to MetaDisplay guard_window to MetaX11Display https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 17:03:51 +00:00
MetaWindow *old_window = meta_display_lookup_stack_id (tracker->display, windows[old_pos]);
Don't restack windows while we are unmanaging them Restacking the frame for a window while unmanaging the window is harmless, but for undecorated (in particular, client-side-decorated) windows, this causes problems because the window is typically destroyed by the client immediately after withredrawing the window. Skip windows flagged as being unmanaged when assembling the new stack and when comparing the old order to the new stack. Add a stacking test for this.
2014-09-16 17:40:30 +00:00
if ((old_window && !old_window->override_redirect && !old_window->unmanaging) ||
core: Check X11 display availability before use in MetaStackTracker This object can be generally triggered without a X11 display, so make sure this is alright. For guard window checks, use our internal meta_stack_tracker_is_guard_window() call, which is already no-x11 aware. https://gitlab.gnome.org/GNOME/mutter/merge_requests/730
2019-08-15 22:27:03 +00:00
meta_stack_tracker_is_guard_window (tracker, windows[old_pos]))
Move logic for syncing the stack to the X server into MetaStackTracker stack.c:sync_stack_to_xserver had both code for assembling the desired stack, and code for enforcing the desired stack on the actual stack of X and Wayland windows; the latter part is properly the domain of stack-tracker.c; moving the code to apply the stack there both simplifies it and keeps stack.c more manageable. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-10 15:58:42 +00:00
break;
}
g_assert (old_pos >= 0);
new_pos = n_managed - 1;
if (managed[new_pos] != windows[old_pos])
{
/* Move the first managed window in the new stack above all managed windows */
meta_stack_tracker_raise_above (tracker, managed[new_pos], windows[old_pos]);
meta_stack_tracker_get_stack (tracker, &windows, &n_windows);
/* Moving managed[new_pos] above windows[old_pos], moves the window at old_pos down by one */
}
old_pos--;
new_pos--;
while (old_pos >= 0 && new_pos >= 0)
{
core: Check X11 display availability before use in MetaStackTracker This object can be generally triggered without a X11 display, so make sure this is alright. For guard window checks, use our internal meta_stack_tracker_is_guard_window() call, which is already no-x11 aware. https://gitlab.gnome.org/GNOME/mutter/merge_requests/730
2019-08-15 22:27:03 +00:00
if (meta_stack_tracker_is_guard_window (tracker, windows[old_pos]))
Move logic for syncing the stack to the X server into MetaStackTracker stack.c:sync_stack_to_xserver had both code for assembling the desired stack, and code for enforcing the desired stack on the actual stack of X and Wayland windows; the latter part is properly the domain of stack-tracker.c; moving the code to apply the stack there both simplifies it and keeps stack.c more manageable. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-10 15:58:42 +00:00
break;
if (windows[old_pos] == managed[new_pos])
{
old_pos--;
new_pos--;
continue;
}
Move stack tracking and guard_window outside of MetaScreen Move stack, stack_tracker to MetaDisplay guard_window to MetaX11Display https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 17:03:51 +00:00
MetaWindow *old_window = meta_display_lookup_stack_id (tracker->display, windows[old_pos]);
Don't restack windows while we are unmanaging them Restacking the frame for a window while unmanaging the window is harmless, but for undecorated (in particular, client-side-decorated) windows, this causes problems because the window is typically destroyed by the client immediately after withredrawing the window. Skip windows flagged as being unmanaged when assembling the new stack and when comparing the old order to the new stack. Add a stacking test for this.
2014-09-16 17:40:30 +00:00
if (!old_window || old_window->override_redirect || old_window->unmanaging)
Move logic for syncing the stack to the X server into MetaStackTracker stack.c:sync_stack_to_xserver had both code for assembling the desired stack, and code for enforcing the desired stack on the actual stack of X and Wayland windows; the latter part is properly the domain of stack-tracker.c; moving the code to apply the stack there both simplifies it and keeps stack.c more manageable. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-10 15:58:42 +00:00
{
old_pos--;
continue;
}
meta_stack_tracker_lower_below (tracker, managed[new_pos], managed[new_pos + 1]);
meta_stack_tracker_get_stack (tracker, &windows, &n_windows);
/* Moving managed[new_pos] above windows[old_pos] moves the window at old_pos down by one,
* we'll examine it again to see if it matches the next new window */
old_pos--;
new_pos--;
}
stack-tracker: Fix an off-by-one error in restack_managed When restacking the last window alone, we would trigger this off-by-one error. This would throw us off the end of the array, causing lower_below warnings for nonsensical values. Since the last window already is lowered below everything else, we shouldn't need to lower it.
2014-09-12 23:10:34 +00:00
while (new_pos > 0)
Move logic for syncing the stack to the X server into MetaStackTracker stack.c:sync_stack_to_xserver had both code for assembling the desired stack, and code for enforcing the desired stack on the actual stack of X and Wayland windows; the latter part is properly the domain of stack-tracker.c; moving the code to apply the stack there both simplifies it and keeps stack.c more manageable. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-10 15:58:42 +00:00
{
meta_stack_tracker_lower_below (tracker, managed[new_pos], managed[new_pos - 1]);
new_pos--;
}
}
void
meta_stack_tracker_restack_at_bottom (MetaStackTracker *tracker,
const guint64 *new_order,
int n_new_order)
{
guint64 *windows;
int n_windows;
int pos;
meta_stack_tracker_get_stack (tracker, &windows, &n_windows);
for (pos = 0; pos < n_new_order; pos++)
{
if (pos >= n_windows || windows[pos] != new_order[pos])
{
if (pos == 0)
meta_stack_tracker_lower (tracker, new_order[pos]);
else
meta_stack_tracker_raise_above (tracker, new_order[pos], new_order[pos - 1]);
meta_stack_tracker_get_stack (tracker, &windows, &n_windows);
}
}
Move manipulation of the X stack to MetaStackTracker Since MetaStackTracker is the code that knows about the current X stacking order and the relationship between X windows and Wayland windows, it's cleaner to encapsulate stack manipulation in MetaStackTracker rather than have the calling code make the X calls and only call into MetaStackTracker to inform it about the changes. https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-09 19:44:26 +00:00
}
Copy permalink