At the moment when a legacy X11 application client is first mapped it
gets briefly shown as a black rectangle before redrawing.
That behavior is because the initial Configure operation on the window
leads to the surface immediately getting full window damage posted by
Xwayland before the client has a chance to draw.
This commit changes mutter to send a sync request right away, when a
window first shows up, then waits until the reply from the application
before showing the window.
It leverages the same code paths already used to prevent flicker from
subsequent (non-initial) resizes on the window.
mutter synchronizes drawing and resizes with Xwayland applications using
XSYNC counters, but it doesn't synchronize drawing and resizes with its
own titlebar painting code.
This commit makes mutter wait until the titlebar finishes drawing before
it unfreezes the corresponding window actor. This ensures the titlebar
and client area don't get out of sync with each other.
Right now meta_compositor_sync_updates_frozen will crash if it's called
on a window that's not yet managed.
For future convenience, make it be a no-op instead, in the same way:
meta_compositor_window_shape_changed
and
meta_compositor_window_opacity_changed
are no-ops for unmanaged windows.
As mentioned in the previous commit, resizing an Xwayland client is an
asynchronous operation.
This commit makes sure we don't allow there to be two resizes in flight
at the same time. We shouldn't resize the window until we've drawn the
window from this step of the resize.
mutter uses the windows "buffer rect" to determine how big to draw the
titlebar, and what masks to apply to the window for opaque areas.
That buffer rect is updated the moment we initiate a resize operation on
a window, but not actually accurate until the resize operation finishes
This commit makes sure the window actor keeps using its old shapes and
masks until any pending resize operation finishes.
For Xwayland clients, resizing is an asynchronous operation. First, the
window manager part of mutter resizes the frame and client window, then
Xwayland waits for damage from the client, and commits a new surface to
the display server part of mutter.
In order to prevent flicker, we need to know when an initiated resize
operation has fully come out the other end of that multi-step process as
a new surface.
This commit lays the plumbing work for preventing the aforementioned
flicker problem, by adding a new resize_pending flag (and associated
accessors), and setting the flag appropriately based on when a resize
is started and subsequently when a new surface is attached.
Right now we defer processing damage on frozen actors, but don't defer
processing surface changes on frozen actors (like for instance when the
surface is changed during a resize).
This commit stops the compositor from processing xwayland client events
for a surface when the actor associated with it is frozen waiting for
the client to draw on the underlying window.
By deferring xwayland client event processing, we'll ensure the surface
commit comes after the corresponding sync counter update from the app,
and ensure we don't update the surface associated with an X window
until after client has finished drawing.
MetaSurfaceActor can be made "frozen" via it's set_frozen method.
That method could be useful as virtual function, so that the wayland
subclass can tie into it and freeze the underlying surface.
This commit does the prerequiste work of making set_frozen a vfunc.
A future commit will change the wayland subclass code to leverage
the vfunc.
Anytime the surface is changed, we need to rebuild our masks and
recalculate our shapes since the new surface may have a different
size.
If the actor gets redrawn for any reason before that computation
happens then it will misrender.
This commit makes sure we do the recomputation right away, before
any painting might occur.
At the moment we only disarm the watchdog timer set up for SYNC counter
requests if we're in the middle of a resize operation.
It's possible that the resize operation finished prematurely by the user
letting go of the mouse before the client responded. If that happens, when the
client finally updates mutter will erroneously still have the watchdog timer
engaged from before until it times out, leading to resizes for the next second
or so to not get processed, and the client to get blacklisted from future sync
requests.
Rotating an output would show duplicate cursors when the pointer is
located over an area which would be within the output if not rotated.
Make sure to swap the width/height of the output when rotated.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/85
Rendering the next frame (which mostly happens as part of the flush done
in swap buffers) is a task that the GPU can complete independently of
the CPU having to wait for previous page flips. So reverse their order
to get the GPU started earlier, with the aim of greater GPU-CPU
parallelism.
When using two monitors size by side with different scales, once the
cursor moves from one output to another one, its size changes based on
the scale of the given output.
Changing the size of the cursor can cause the cursor area to change
output again if the hotspot is not exactly at the top left corner of the
area, causing the texture of the cursor to change, which will trigger
another output change, so on and so forth causing continuous surface
enter/leave event which flood the clients and eventually kill them.
Change the logic to use only the actual cursor position to determine if
its on the given logical monitor, so that it remains immune to scale
changes induced by output scale differences.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/83
We can save an unnecessary relayout if the required size to fully draw the text
is equal to the currently allocated size after the underlying text buffer or
attributes that only affect the PangoLayout have changed.
This commit allows building mutter with elogind, which is
systemd-logind extracted into a standalone package. This
allows using mutter with its native-backend ( and consequently
wayland ) enabled on distros which use init systems other than
systemd.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/46
By the looks of it, commit 95e9fa10ef was taping over an Intel DRI bug
that would make it return post-swizzling pixel data on glReadPixels().
There's been reports over time of that commit resulting in wrong colors
on other drivers, and lately Mesa >17.3 started showing the same symptoms
on Intel.
But texture swizzling works by changing parameters before fragment shaders
and reading pixels from an already drawn FBO/texture doesn't involve those.
This should thus use pixel_format_to_gl_with_target(), which will result in
correctly requesting the same pixel format than the underlying texture,
while still considering it BGRA for the upper layers in the swizzling case.
https://gitlab.gnome.org/GNOME/mutter/issues/72Closes: #72
This state tracks hardware devices' state, thus shouldn't be triggered by
events that were emulated/forwarded by the IM. Those may include modifiers
and would result in xkb_state being doubly set, and possibly stuck.
https://gitlab.gnome.org/GNOME/mutter/issues/74Closes: #74
Actor keybindings were dispatched in an earlier return path, which means
the IM doesn't get to see certain key events. Flip the order around so the
IM has an opportunity to handle all keypresses.
https://gitlab.gnome.org/GNOME/mutter/issues/65Closes: #65
Commit d714a94d9 added support for stable xdg-shell surfaces while
preserving old unstable zxdg-shell v6 ones, but committed a mistake
in checking for both in the xdg_exporter.export error condition
paths. We want to check that the surface is neither of both.
https://gitlab.gnome.org/GNOME/mutter/issues/63Closes: #63
Raising and lowering windows in tandem without a proper grouping
mechanism ended up being more annoying than functional.
This reverts commit e76a0f564c.
We just arbitrarily chose the first EGL config matching the passed
attributes, but we then assumed we always got GBM_FORMAT_XRGB8888. That
was not a correct assumption. Instead, make sure we always pick the
format we expect.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/2
When painting the titlebar, button icons that aren't available in the
desired size need to be scaled. However the current code inverses the
scale factor, with the result that the adjusted icons are much worse
than the original icons, whoops.
This went unnoticed for a long time given that most icons are availa-
ble in the desired 16x16 size, and the most likely exceptions - window
icons - are not shown by default.
https://gitlab.gnome.org/GNOME/mutter/issues/23
