summaryrefslogtreecommitdiff
path: root/src/core/stack-tracker.c
Commit message (Collapse)AuthorAgeFilesLines
* compositor: Don't make internal API publicJonas Ådahl2022-12-171-1/+1
| | | | | | | | | | | | | | | Things like meta_compositor_destroy() and meta_compositor_add_window() isn't intended to be used externally, and if they was, things would probably fall apart rather quickly. MetaCompositor also isn't introspected, meaning things that technically belong to the compositing parts isn't easily available via some object, but much take detours via other objects like MetaDisplay. So move the API intended for internal usage to compositor-private.h, and leave API that is meant to be expose in the public compositor.h. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
* core: Setup and use ownership chainsJonas Ådahl2022-12-171-8/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As with other parts, make objects have the ability to walk up the ownership chain to the context, to get things like the Wayland compositor or backend instances. Contains these squashed commits: display: Don't get backend from singleton window: Don't get backend from singleton keybindings: Don't get backend from singleton workspace: Don't get backend from singleton display: Don't get Wayland compositor from singleton selection: Add display getter context/main: Get backend directly from the context clipboard-manager: Don't get display from singleton stack-tracker: Don't use singleton MetaLater API startup-notification: Hook up sequences and activations to display This allows using context aware API directly. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
* util: Remove push/pop no msg prefix loggingJonas Ådahl2021-11-211-4/+0
| | | | | | | | Used to log multiple line entries. Just make continue prefix things, no need to mess with maybe-prefixing; it'll just complicate using some less custom logging functionality. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2094>
* src: Stop using GSliceRobert Mader2021-02-221-5/+5
| | | | | | | | It has been inofficially deprecated for years, is known to cause issues with valgrind and potentially hides memory corruption. Lets stop using it. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1512>
* stack: Add some trace instrumentationJonas Ådahl2020-12-011-0/+16
| | | | | | | | The stack and stack tracker tend to cause missed frames from time to time, especially when there are many open windows. Add some instrumentation to make it this easily verifiable when profiling. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1616>
* Make meta_* logging utilities not require line breakJonas Ådahl2020-10-081-8/+7
| | | | | | | | Unlike g_* logging utilities, the meta_* counterparts behave like odd printf() functions. Lets change that so they fit better into how logging is done everywhere else. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1466
* stack-tracker: Don't log warnings on race conditionsJonas Ådahl2020-06-091-12/+18
| | | | | | | | | | | | | X11 window stacking operations are by nature prone to race conditions. For example, we might queue a "raise above" operation, but before it actually takes place, the sibling the window was to be rased above, is withdrawn. In these cases we'd log warnings even though they are expected to happen. Downgrade these warnings to debug messages, only printed when MUTTER_VERBOSE is set. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1300
* stack-tracker: Fix coding style of meta_stack_op_apply()Jonas Ådahl2020-06-091-66/+76
| | | | | | Change tabs to spaces, clean up variable declarations. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1300
* core: Split x11-display initialization in 2 signalsCarlos Garnacho2019-09-111-1/+1
| | | | | | | | | | 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
* core: Check X11 display availability before use in MetaStackTrackerCarlos Garnacho2019-08-261-4/+6
| | | | | | | | 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
* core: Prepare MetaStackTracker for X11 display being closedCarlos Garnacho2019-08-061-0/+43
| | | | | | | | | | 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
* Use a consistent style for enum bracesNiels De Graef2019-02-281-2/+4
| | | | https://gitlab.gnome.org/GNOME/mutter/merge_requests/361
* Fix warnings when building without verbose modeJonas Ådahl2018-11-061-0/+6
|
* Clean up include macros messJonas Ådahl2018-11-061-9/+8
| | | | | | 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.
* stack-tracker: Don't sort O-R's under guard window on topJonas Ådahl2018-07-171-1/+19
| | | | | | | | | | | | | | 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.
* Rename errors.[ch] to meta-x11-errors.[ch]Armin Krezović2018-07-061-5/+5
| | | | | | | 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
* Make stack tracker work without X11Armin Krezović2018-07-061-8/+18
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=759538
* Move stack tracking and guard_window outside of MetaScreenArmin Krezović2018-07-061-21/+21
| | | | | | Move stack, stack_tracker to MetaDisplay guard_window to MetaX11Display https://bugzilla.gnome.org/show_bug.cgi?id=759538
* Move alarm and xids management to MetaX11DisplayArmin Krezović2018-07-061-1/+2
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=759538
* Switch meta_error_trap functions to MetaX11DisplayArmin Krezović2018-07-061-4/+4
| | | | | | | | They are X11 specific functions, used for X11 code. They have been improved per jadahl's suggestion to use gdk_x11_lookup_xdisplay and gdk_x11_display_error_trap_* functions, instead of current code. https://bugzilla.gnome.org/show_bug.cgi?id=759538
* Start populating MetaX11DisplayArmin Krezović2018-07-061-7/+11
| | | | | | | | | | | - 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
* stack-tracker: Keep override redirect windows on topRui Matos2017-07-141-0/+36
| | | | | | | | | | | | | 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
* Always use the default screenJonas Ådahl2016-07-231-1/+1
| | | | | | | | | 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
* Don't restack windows while we are unmanaging themOwen W. Taylor2014-09-161-2/+3
| | | | | | | | | | | | 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.
* stack-tracker: Fix an off-by-one error in restack_managedJasper St. Pierre2014-09-121-1/+1
| | | | | | | | | 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.
* stack-tracker: Make lower_below / raise_above internal as wellJasper St. Pierre2014-09-121-9/+9
| | | | These are unused elsewhere.
* MetaStackTracker: optimize out unnecessary X restackingOwen W. Taylor2014-09-121-22/+30
| | | | | | | | | | | | | | | | | | | | 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
* MetaStackTracker: make functions used only internally staticOwen W. Taylor2014-09-121-10/+2
| | | | | | | | 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
* Move logic for syncing the stack to the X server into MetaStackTrackerOwen W. Taylor2014-09-121-14/+93
| | | | | | | | | 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
* Move manipulation of the X stack to MetaStackTrackerOwen W. Taylor2014-09-121-48/+147
| | | | | | | | | | 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
* MetaStackTracker: eliminate the resynchronization processOwen W. Taylor2014-09-121-352/+128
| | | | | | | | | | | | | | | | 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
* Replace MetaStackWindow with a 64-bit "stack ID"Owen W. Taylor2014-09-121-237/+153
| | | | | | | | | | | | | | | | | | | | 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
* stack-tracker: More small cleanupsJasper St. Pierre2014-07-101-9/+2
|
* stack-tracker: Remove unused variableJasper St. Pierre2014-07-101-10/+2
|
* stack-tracker: Add some more debug outputJasper St. Pierre2014-07-101-0/+5
|
* stack-tracker: Clean up dumpingJasper St. Pierre2014-07-101-24/+21
|
* stack-tracker: Fix the case where the serial is too oldJasper St. Pierre2014-07-101-8/+5
| | | | | The code here before was just flat out wrong, and made us consistently requery the server at startup.
* stack-tracker: Fix code styleJasper St. Pierre2014-07-101-19/+9
|
* stack-tracker: Fix commentsJasper St. Pierre2014-07-101-5/+5
|
* MetaStackTracker: make sure all stack ops are freed eventuallyGiovanni Campagna2014-05-071-1/+11
| | | | | | | | | 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
* Remove trailing whitespaceJasper St. Pierre2014-05-021-1/+1
|
* stack-tracker: Fix unitialized variableAdel Gadllah2014-04-201-1/+1
|
* compositor: Kill off MetaCompScreenJasper St. Pierre2014-03-261-1/+0
| | | | | | | | | Compositors haven't been able to manage more than one screen for quite a while. Merge MetaCompScreen into MetaCompositor, and update the API to match. We still keep MetaScreen in the public compositor API for compatibility purposes.
* Assume the compositor always existsJasper St. Pierre2014-03-181-4/+3
| | | | | | | 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.
* stack-tracker: Comment out bad warningJasper St. Pierre2014-02-241-1/+1
| | | | | | It triggers too often, making G_DEBUG=fatal-warnings quite useless. Owen is going to rewrite this code sometime in the near future, so I'm just gonna kill this warning for now.
* Changed obsolete FSF postal address into generic URL.Andika Triwidada2014-01-131-3/+1
| | | | Fix https://bugzilla.gnome.org/show_bug.cgi?id=721517 #2
* Fix distcheckGiovanni Campagna2013-09-031-1/+0
| | | | Missing translation files, missing dists and some -Werrors.
* Add support for stacking X and Wayland windows togetherRobert Bragg2013-08-101-173/+702
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* MetaScreen: Add tracking of whether there are fullscreen windowsOwen W. Taylor2013-03-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | 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
* Fix gobs of gtk-doc warningsTomeu Vizoso2013-03-141-1/+16
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=676856
View Lorry Controller Status