g_idle_add() makes no guarantee about when it will be run - if Mutter
is busy drawing and blocking glXSwapBuffers() it could happen only
minutes later. Use meta_later_add (META_LATER_BEFORE_REDRAW) instead -
this will deterministically be run after the Wayland socket is read
from but before the next frame is painted.
https://bugzilla.gnome.org/show_bug.cgi?id=736694
We shouldn't scale the cursor size in mutter we g-s-d exports
the correct size on hidpi so use gtk-cursor-theme-size.
This way we also catch changes on resolution updates.
https://bugzilla.gnome.org/show_bug.cgi?id=729337
This reverts commit 4fe66ce0a9.
This is wrong ... we should not scale the cursor size but read
the cursor xsettings that gets exported by gsd. Also this won't update on
resolution changes.
https://bugzilla.gnome.org/show_bug.cgi?id=729337
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.
The merge of the commit af46ef3b 'meta_window_new: clean up error handling'
to the wayland branch accidentally added an extra call to meta_error_trap_push(),
meaning that we leaked one level of error traps for each new window.
Fixes warning:
Gdk-WARNING **: XSetErrorHandler() called with a GDK error trap pushed.
https://bugzilla.gnome.org/show_bug.cgi?id=736589
When the screen resizes, we get a configure event for the composite overlay
window - don't pass that to MetaStackTracker, since the COW isn't in the
stack.
Fixes warning:
mutter-WARNING **: STACK_OP_RAISE_ABOVE: window 0x65 not in stack
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
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
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
There was still code in stack.c to handle skipping override-redirect windows,
but since quite a while ago, meta_stack_add() is not called for OR windows
since they are outside our stacking control. Add an assertion and remove
unnecessary code.
https://bugzilla.gnome.org/show_bug.cgi?id=736559
stack.c kept it's own record of the last stacking it requested, so that
restacking could be done with minimal moves, but we already have a better
view of the stacking order with the stack tracker, so use that instead.
This allows eliminating the special case for the first restack.
https://bugzilla.gnome.org/show_bug.cgi?id=736559
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
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
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
Add a basic framework for tests of Mutter handling of client behavior;
mutter-test-runner is a Mutter-based compositor that forks off instances
of mutter-test-client and sends commands to them based on scripts.
The scripts also include assertions.
mutter-test-runner always runs in nested-Wayland mode since the separate
copy of Xwayland is helpful in giving a reliably clean X server to
test against.
Initially the commands and assertions are designed to test the stacking
behavior of Mutter, but the framework should be extensible to test other
parts of client behavior like focus.
The tests are installed according to:
https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests
if --enable-installed-tests is passed to configure. You can run them
uninstalled with:
cd src && make run-tests
(Not in 'make check' to avoid breaking 'make distcheck' if Mutter can't be
run nested.)
https://bugzilla.gnome.org/show_bug.cgi?id=736505
For reasons related to interaction between the GTK+ CSS code and the
frame sync protocol, the dummy GtkWindow that MetaUI creates to track
theme properties has to be mapped and have MetaWindow associated with it.
Add a private function so that the test framework can filter this out.
https://bugzilla.gnome.org/show_bug.cgi?id=736505
Add a private hook for the test framework to get XSyncAlarmEvent events -
this will be used to implement XSyncCounter based synchronization
so that the test framework can deterministically wait until Mutter
has seen actions performed by an X11 client.
https://bugzilla.gnome.org/show_bug.cgi?id=736505
Add private functions for the test framework to use to find out the
wayland and x11 display names, so they can set up the environment for
children.
https://bugzilla.gnome.org/show_bug.cgi?id=736505
We'll need this in the wayland frontend to send a modifiers event to
clients.
Note that on X11 this isn't needed because key events include the
group index encoded in modifier state. If we ever want to make the
wayland frontend work with the X11 backend we'll handle it then.
https://bugzilla.gnome.org/show_bug.cgi?id=736433
According to the documentation, the method returns "whether the X window
that the actor was displaying has been destroyed" - that is very much
true when we delay the actual actor destruction for a destroy animation,
so update the method accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=735927
When a window is destroyed, the corresponding actor may still be
kept around for the destroy effect. But as the actor is removed
from the compositor's stack list immediately, the compositor will
always stack it above "valid" window actors - this is not what we
want, so only update the compositor's list when the actor is
actually destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=735927
Setting the scaling factor immediately after calling clutter_init()
avoids creating the stage at one size, then later resizing it to
a different size.
https://bugzilla.gnome.org/show_bug.cgi?id=736279
In the case of a nested Wayland compositor inside an X session,
Clutter is managing the toplevel window size, so don't call
XResizeWindow on it - this will confuse Clutter and get the size
and the hints out of sync on the toplevel window.
https://bugzilla.gnome.org/show_bug.cgi?id=736279
It's possible for a released pointer to have repick / set_focus on it as
part of sync_input_focus. When the pointer is actually re-init'd, it
will memset 0, which can cause corruption as our destroy listener has
already been added.
Released devices should be idempotent, so just make sure method calls on
them don't have any effect.
We can enter weird states where get_default_window is called during
window unmanagement, before the window has been fully removed from
the stack. Make sure these windows are *never* returned from
get_default_window, as focusing them can cause an assertion fail,
or worse.
If we add device 2, then add device 254, then remove device 254, then
the max device ID will be 253. Scan through all the devices again on
removal to calculate a new max device ID.
Rather than have the DBus code control this, move this into
MetaBackend. This also lets us destroy idle monitors when appropriate,
rather than leaking them forever.
Not having a paint volume causes every single paint to turn into
full-stage redraw, since otherwise culling won't properly work.
Since we don't paint outside of our allocation, just use the simple
default implementation, but also return TRUE inside it.
Make the vignette options properties so they can be animated;
modify the function-call API for meta_background_actor_set_vignette()
to correspond more closely to the 3 properties.
https://bugzilla.gnome.org/show_bug.cgi?id=735637
Without GLSL, we didn't apply the vignetting, which not only made the
background uniform in color, it made it much lighter. Adjust for this
and make the average brightness with the vignette effect the same
with or without GLSL.
https://bugzilla.gnome.org/show_bug.cgi?id=735637
The old requirement that multiple MetaBackgroundActor objects be
layered on top of each to produce blended backgrounds resulted in
extremely inefficient drawing since the entire framebuffer had
to be read and written multiple times.
* Replace the MetaBackground ClutterContent with a plain GObject
that serves to hold the background parameters and prerender
textures to be used to draw the background. It handles
colors, gradients, and blended images, but does not handle
vignetting
* Add vignetting to MetaBackgroundActor directly.
* Add MetaBackgroundImage and MetaBackgroundImageCache to allow
multiple MetaBackground objects to share the same images
By removing the usage of ClutterContent, the following optimizations
were easy to add:
Blending is turned off when the actor is fully opaque
Nearest-neighbour filtering is used when drawing 1:1
The GLSL vignette code is slightly improved to use a vertex shader
snippet for computing the texture coordinate => position in actor
mapping.
https://bugzilla.gnome.org/show_bug.cgi?id=735637
The old check for using NEAREST by checking clutter_actor_is_in_clone_paint()
and meta_actor_is_untransformed (actor) doesn't work properly since
clutter_actor_is_in_clone_paint() does not look at ancestors of the
actor; it only applies to a direct clone of the actor. Using
meta_actor_painting_untransformed() allows us to check exactly what we
care about rather than using tricky approximations.
https://bugzilla.gnome.org/show_bug.cgi?id=735632
The painting_untransformed() function in MetaWindowGroup is useful
elsewhere, in particular if we want to check whether we can avoid
bilinear filtering when painting a texture 1:1.
https://bugzilla.gnome.org/show_bug.cgi?id=735632
Clutter events include the layout index codified into modifier_state,
unlike XI2 device events, which means that we need to mask it out so
that we can match successfully.
A lot of applications assume that the window is fully positioned when it
gets the MapNotify, especially simple applications. Make sure that the
window is only mapped through the calc_showing logic.
meta_surface_actor_is_argb32 assumes that lack of stex means that a window is
ARGB32. When we unredirect a window we detach the texture so we end up without
a texture. Given that should_unredirect returns FALSE when a window is argb32,
we know that this window is indeed not ARGB32.
Returing TRUE in that case causes us to flip between redirected and
unredirected on every paint.
So fix that by returning FALSE in that case.
A wl_surface may have a wl_subsurface interface, but no buffers attached
yet, even though the geometry calculation code for surfaces/subsurfaces
assumes everything has already a buffer.
Just skip subsurfaces that don't have a buffer, those can't be set
a geometry yet, and right now it's crashing accessing the texture from
the NULL surface->buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=735452
When the blended region was empty, meaning we didn't have to paint
anything blended -- the case for an app update -- was drawing the
entire window blended, because of a think-o in the complex and
complicated logic.
Fix this so that we don't draw anything for the blended region when
empty.
O-R windows appear in workspace->windows, which aren't relocatable,
so we can't simply check if the workspace is empty after relocating
all normal windows, since those windows remain.
Make sure that the only windows we have are those that are
on_all_workspaces.
region first
If we're going to render the entire texture blended, then don't bother
painting the unblended stuff, since we're just going to draw on top
anyway.
We indeed call this function if we're not an X11 compositor, but in this
case we're simply calling it to say that we have no cursor overlay. Make
sure not to assert fail in this case.
This makes it so that MetaSurfaceActorWayland is effectively just a
wrapper actor around MetaShapedTexture with some extra scaling. I think
the MetaSurfaceActor subclassing was a bad idea -- we really should have
these abstractions in much higher levels in the stack than the
compositor.
It doesn't make sense to update it in the surface actor. It's also
theoretically wrong to update the buffer's texture on surface commit,
too, because it's buffer state, not surface state, but I don't think
there's any place we use a wl_buffer without a wl_surface.
This is bad behavior, and can also cause us to get in an infinite loop
if an OR window is mapped and unmapped in quick succession. This
sequence causes a MapNotify followed by an UnmapNotify, and when
processing the events, we'll call XMapWindow, XUnmapWindow, which will
put another set of MapNotify, UnmapNotify events in our queue, which we
then process by calling XMapWindow, XUnmapWindow, and so it goes
forever, or at least some scheduler uncorks us by making us call
XMapWindow when the window is already mapped, or XUnmapWindow when the
window is already unmapped.
We can stop this madness by simply making sure never to call neither
XMapWindow or XUnmapWindow on OR windows, which is the correct thing to
do anyway.
This was the original intention, but it was thought to be easier
to mark this as a combination of all directions. It turned out to
instead cause subtle bugs since code that blindly checked & DIR_WEST or
similar turned out to get it wrong when it was UNKNOWN, so just make
it an explicit flag.
This fixes the cursor appearing in the wrong place when starting a
keyboard resize.
We commonly used the generic, undetailed signal 'changed' to track
changes to preferences. Since we crash on unknown preference types,
this can be dangerous if somebody adds a new setting that has a
type we're unfamiliar with, and something else changes it.
Instead of crashing, just fizzle out doing nothing.
In gnome-shell, we have a feature where the user can unmaximize windows
by dragging them from the panel above the window. With accurate
anchoring, this looks really weird as the cursor is now "detached" from
the window. Detect this case and put the cursor in the middle of the
window titlebar instead.
