The sync ring has an API about "frames", where it is notified about
the end of frames. However, its "insert wait" call is done before
updates, meaning that some "insert waits" will never see the "after
frame" if there was no frame drawn. This will cause mismatching in the
frame counting, causing freezes in the synchronization until something
else triggers an actual frame, effectively "unfreezing" the sync ring.
Fix this by not only notifying the sync ring about frames when there
were actual frames drawn, but also on plain updates which didn't result
in a drawn frame.
Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/1516
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1754>
Ensure we issue a motion event for the current pointer position,
as there might be situations where compositor modals get X grabs
from other clients stacked on top, or missed events in between
otherwise.
Ensure the Clutter state is still up-to-date afterwards here. This
replaces some sync_pointer() calls done in GNOME Shell code, always
done after modality changes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1659>
Do these Wayland operations (that apply on both native and nested backends)
in the MetaCompositorServer subclass. We want to add more backend specific
behavior here in the future.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1659>
The timestamp sent with _NET_WM_FRAME_DRAWN should be in "high
resolution X server timestamps", meaning they should have the same scope
as the built in X11 32 bit unsigned integer timestamps, i.e. overflow at
the same time.
This was not done correctly when mutter had determined the X server used
the monotonic clock, where it'd just forward the monotonic clock,
confusing any client using _NET_WM_FRAME_DRAWN and friends.
Fix this by 1) splitting the timestamp conversiot into an X11 case and a
display server case, where the display server case simply clamps the
monotonic clock, as it is assumed Xwayland is always usign the monotonic
clock, and 2) if we're a X11 compositing manager, if the X server is
using the monotonic clock, apply the same semantics as the display
server case and always just clamp, or if not, calculate the offset every
10 seconds, and offset the monotonic clock timestamp with the calculated
X server timestamp offset.
This fixes an issue that would occur if mutter (or rather GNOME Shell)
would have been started before a X11 timestamp overflow, after the
overflow happened. In this case, GTK3 clients would get unclamped
timestamps, and get very confused, resulting in frames queued several
weeks into the future.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1494
Replace the default master clock with multiple frame clocks, each
driving its own stage view. As each stage view represents one CRTC, this
means we draw each CRTC with its own designated frame clock,
disconnected from all the others.
For example this means we when using the native backend will never need
to wait for one monitor to vsync before painting another, so e.g. having
a 144 Hz monitor next to a 60 Hz monitor, things including both Wayland
and X11 applications and shell UI will be able to render at the
corresponding monitor refresh rate.
This also changes a warning about missed frames when sending
_NETWM_FRAME_TIMINGS messages to a debug log entry, as it's expected
that we'll start missing frames e.g. when a X11 window (via Xwayland) is
exclusively within a stage view that was not painted, while another one
was, still increasing the global frame clock.
Addititonally, this also requires the X11 window actor to schedule
timeouts for _NET_WM_FRAME_DRAWN/_NET_WM_FRAME_TIMINGS event emitting,
if the actor wasn't on any stage views, as now we'll only get the frame
callbacks on actors when they actually were painted, while in the past,
we'd invoke that vfunc when anything was painted.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/903
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
The repaint callbacks are not tied to repaint, thus a bit misleading.
What the functionality in the pre/post-paint callbacks here cares about
is when actually painting; the non-painting related parts has already
moved out to a *-update signal.
This also renames the related MetaWindowActorClass vfuncs, to align with
naming convention of the signals that it listens to.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
The synchronization must happen no matter the painting, as it in itself
might result in reported damage, making the stage actually painted. Thus
move it out of the "pre-paint" handler, to something explicitly not tied
to the painting itself - ClutterStage::before-update.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
We would get the MetaDisplay from the backend singleton before creating
the MetaCompositor, then in MetaCompositor, get the backend singleton
again to get the stage. To get rid of the extra singleton fetching, just
pass the backend the MetaCompositor constructors, and fetch the stage
directly from the backend everytime it's needed.
This also makes it available earlier than before, as we didn't set our
instance private stage pointer until the manage() call.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1289
MetaCompositor is the place in mutter that manages the higher level
state of compositing, such as handling what happens before and after
paint. In order for other units that depend on having a compositor
instance active, but should be initialized before the X11 implementation
of MetaCompositor registers as a X11 compositing manager, split the
initialization of compositing into two steps:
1) Instantiate the object - only construct the instance, making it
possible for users to start listening to signals etc
2) Manage - this e.g. establishes the compositor as the X11 compositing
manager and similar things.
This will enable us to put compositing dependent scattered global
variables into a MetaCompositor owned object.
For now, compositor management is internally done by calling a new
`meta_compositor_do_manage()`, as right now we can't change the API of
`meta_compositor_manage()` as it is public. For the next version, manual
management of compositing will removed from the public API, and only
managed internally.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
Given that on Wayland we are pretty much guaranteed to finish MetaX11Display
setup after the MetaCompositor is enabled, we may drop the
meta_compositor_manage() x11 initialization bits, and move them into the
MetaX11Compositor subclass where it's actually needed.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/944
Move out updating of various shapes (input, opaque, shape) indirectly
from X11 to the corresponding X11 sub types of MetaWindowActor and
MetaSurfaceActor.
Also move fullscreen window unredirection code with it. We want to
effectively do something similar for MetaCompositorServer, but it will
work differently enough not to share too much logic.
While it would have been nice to move things piece by piece, things were
too intertwined to make it feasible.
This has the side effect fixing accidentally and arbitrarily adding
server side shadow to Wayland surfaces.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/727https://gitlab.gnome.org/GNOME/mutter/merge_requests/734
The end goal is to have all clutter backend code in src/backends. Input
is the larger chunk of it, which is now part of our specific
MutterClutterBackendX11, this extends to device manager, input devices,
tools and keymap.
This was supposed to be nice and incremental, but there's no sane way
to cut this through. As a result of the refactor, a number of private
Clutter functions are now exported for external backends to be possible.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/672
A base type shouldn't know about sub types, so let MetaDisplay make
the correct choice of what type of MetaCompositor it should create. No
other semantical changes introduced.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/727
Introduce MetaCompositorX11, dealing with being a X11 compositor, and
MetaCompositorServer, being a compositor while also being the display
server itself, e.g. a Wayland display server.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/727
