isa/mutter
1
0
Fork 0
mirror of https://github.com/brl/mutter.git synced 2024-11-23 16:40:41 -05:00
Code Issues Packages Projects Releases Wiki Activity
5b7dff7a57
mutter/src/core/stack-tracker.h

107 lines
4.6 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 16:45:32 -04:00
/* -*- mode: C; c-file-style: "gnu"; indent-tabs-mode: nil; -*- */
/**
* \file stack-tracker.h 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.
*/
/*
* 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-11 20:42:06 -05: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 16:45:32 -04:00
*/
#ifndef META_STACK_TRACKER_H
#define META_STACK_TRACKER_H
Move the installed includes to a subdir If mutter is going to be a "real" library, then it should install its includes so that users can do #include <meta/display.h> rather than #include <display.h> So rename the includedir accordingly, move src/include to src/meta, and fix up all internal references. There were a handful of header files in src/include that were not installed; this appears to have been part of a plan to keep core/, ui/, and compositor/ from looking at each others' private includes, but that wasn't really working anyway. So move all non-installed headers back into core/ or ui/. https://bugzilla.gnome.org/show_bug.cgi?id=643959
2011-03-05 19:29:12 -05:00
#include <meta/screen.h>
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 06:22:13 -04:00
#include <meta/window.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 16:45:32 -04:00
typedef struct _MetaStackTracker MetaStackTracker;
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 06:22:13 -04:00
typedef union _MetaStackWindow
{
struct {
MetaWindowClientType type;
} any;
struct {
MetaWindowClientType type;
Window xwindow;
} x11;
struct {
MetaWindowClientType type;
MetaWindow *meta_window;
} wayland;
} MetaStackWindow;
gboolean meta_stack_window_equal (const MetaStackWindow *a,
const MetaStackWindow *b);
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 16:45:32 -04:00
MetaStackTracker *meta_stack_tracker_new (MetaScreen *screen);
void meta_stack_tracker_free (MetaStackTracker *tracker);
/* These functions are called when we make an X call that changes the
* stacking order; this allows MetaStackTracker to predict stacking
* order before it receives events back from the X 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 06:22:13 -04:00
void meta_stack_tracker_record_add (MetaStackTracker *tracker,
const MetaStackWindow *window,
gulong serial);
void meta_stack_tracker_record_remove (MetaStackTracker *tracker,
const MetaStackWindow *window,
gulong serial);
void meta_stack_tracker_record_restack_windows (MetaStackTracker *tracker,
const MetaStackWindow *windows,
int n_windows,
gulong serial);
void meta_stack_tracker_record_raise_above (MetaStackTracker *tracker,
const MetaStackWindow *window,
const MetaStackWindow *sibling,
gulong serial);
void meta_stack_tracker_record_lower_below (MetaStackTracker *tracker,
const MetaStackWindow *window,
const MetaStackWindow *sibling,
gulong serial);
void meta_stack_tracker_record_lower (MetaStackTracker *tracker,
const MetaStackWindow *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 16:45:32 -04:00
/* These functions are used to update the stack when we get events
* reflecting changes to the stacking order */
void meta_stack_tracker_create_event (MetaStackTracker *tracker,
XCreateWindowEvent *event);
void meta_stack_tracker_destroy_event (MetaStackTracker *tracker,
XDestroyWindowEvent *event);
void meta_stack_tracker_reparent_event (MetaStackTracker *tracker,
XReparentEvent *event);
void meta_stack_tracker_configure_event (MetaStackTracker *tracker,
XConfigureEvent *event);
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 06:22:13 -04:00
void meta_stack_tracker_get_stack (MetaStackTracker *tracker,
MetaStackWindow **windows,
int *n_entries);
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 08:04:28 -04:00
void meta_stack_tracker_sync_stack (MetaStackTracker *tracker);
void meta_stack_tracker_queue_sync_stack (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 16:45:32 -04:00
#endif /* META_STACK_TRACKER_H */
Reference in New Issue Copy Permalink