While we're now doing a fairly good job at not needing those matrices
all the time anymore, we still need it multiple times during every paint
cycle, so it definitely makes sense to introduce some caching here.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2679>
With commit 5a565b4258, we changed
clutter_actor_finish_layout() to be not only about updating stage views,
but also take care of updating the visible_paint_volume, for that we
started doing a full tree traversal of all mapped actors.
This can be quite a performance issue, apparently especially on certain
ARM devices, where the simple tree traversal can take as long as 2ms.
This is precious time we need to paint our next frame, so lets do a bit
more work to avoid those useless traversals.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/2459
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2679>
We're using clutter_stage_schedule_update() now from ClutterActor to kick
off the stage updating machinery when a redraw needs to happen.
This introduced a bunch of unnecessary calls to
clutter_stage_schedule_update() and thus
clutter_stage_view_schedule_update() when multiple actors request redraws
during the same stage update cycle, which is a very common case.
Cut off all those unnecessary calls by bailing out in
clutter_stage_schedule_update() when updates are already queued.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2679>
Using a list of heap allocated ClutterPaintVolumes adds quite a bit of
unnecessary overhead: It means for every single redraw clip we allocate a
list and a paint volume on the heap.
Let's avoid all those heap allocations by using a GArray with static
ClutterPaintVolumes instead.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2679>
So far our logic for queueing redraws goes like this: Actor notices that it
needs to redraw -> actor tells stage that it needs to redraw via
clutter_stage_queue_actor_redraw() -> stage collects more and more redraws
into a QueueRedrawList before the actual stage update happens -> when
that happens, the stage collects the actual redraw clips from the actors via
clutter_actor_get_redraw_clip().
The logic behind this QueueRedrawList was that by storing a list of
redraw entries on the stage, way we can avoid traversing the whole actor
tree one more time to build the redraw clip before the stage update.
These days we have clutter_actor_finish_layout() though, which is basically
exactly that, a whole actor tree traversal that happens before every stage
update.
Since we have that now, we might as well get rid of the whole dance back and
forth between ClutterStage and ClutterActor, and simply merge the logic to
queue redraws into the finish-layout step.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2679>
If no actors have changed their positions and we're only repainting
because a window needs a repaint, the paint volumes of all actors
remain unchanged. There is no reason to redo those paint volumes on every
stage update.
So introduce caching and invalidation logic for the visible_paint_volume
that allows us to avoid a ton of matrix multiplications that right now
are happening for the whole mapped actor tree on every redraw.
Note that this removes two places where the visible paint volume is set
to an empty paint volume: This is a compromise so that we can keep
around the cached pv when hiding and showing an actor, it does "regress"
one case though: When hiding -> moving -> showing an actor, we'll now
include the old paint volume of the actor in the redraw clip on show (even
though redrawing that old region is not necessary, the actor was hidden
after all). This results in a bit of overpaint in this very specific case,
but for the sake of simplicity let's not care about that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2679>
There were two issues with using the shape region to derive an input
region.
Firstly, the shape region is against the client rectangle, while the
surface actor needs it to be against the buffer rectangle. Fix this by
offsetting the shape region before passing it along.
Secondly, we can't just intersect the shape and input region, since that
leaves out the window decorations. Fix this by only intersecting the
input region covering the client part, and the shape region, and then
union that with the input region covering the rest.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3045>
When building mutter with -Ddebug=false, a warning appears, that
`ClutterStagePrivate *priv` is unused.
Simply remove this variable and directly use `stage->priv` in
`CLUTTER_NOTE` to get rid of this warning.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3046>
Don't try to handle things by threads enabling/disabling the main trace
context on-demand, just have a clear start/stop API. For the D-Bus API,
it becomes more straight forward, and for the persistent variant too, as
it avoids having to pass garbage input when it's known that arguments
will be discarded.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2998>
Persistent profiling was started via an env var, but that's rather hard
to discover and remember without grepping; change to use a command line
argument.
The profiler is started early, even during (though late in)
configuration, but configuration should ideally be instant and pointless
to configure.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2998>
Under X11 hiding the backend implies also unmapping the stage window, if
we do that after that we've closed the display we may end up in a
BadWindow error because such window seems to be destroyed together with
the compositor output parent (even though we are not notified about), so
to prevent this, reparent the backend window during compositor unmanage,
setting it back as a root window child.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2835
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3020>
Original commit message:
> ATM sending modifiers to clients prevents direct scanout for DRI3
> clients via Xwayland. Xwayland using the dma-buf feedback v4 Wayland
> protocol will solve that, but that might take a while yet to appear in
> the wild. Once that happens, this can be reverted.
>
> Direct scanout still works for native Wayland clients as well.
Xwayland got support for v4 in 23.1.0, thus let's reenable modifiers on
AMD.
This reverts commit 2f825f3a86.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3030>
We are now building and testing mutter as user, but the clone may happen
as root, before the docker image takes place.
This may create troubles to git, causing errors such as:
fatal: detected dubious ownership in repository at ...
And we can't fix this using safe.directory option because we have no
control on the system at this scope.
So, let's just handle the cloning manually so that the meta-user is
always the owner of the repository.
This fixes the dist job, but also other jobs that may fail because of
this reason.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3024>
Using the old replace syntax doesn't allow to extend dicts such as
variables or other values, but instead it replaces them.
So use a newer and safer syntax, given we don't need to replace any
parameter where used.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3024>
We currently lock the capability of the MetaOrientationManager to emit
the ::orientation-changed signal, but otherwise keep reading the current
orientation and returning it if we are asked politely through
meta_orientation_manager_get_orientation().
This may bring issues e.g. around suspend/resume, since there may be other
parts of the code trying to get the current orientation without receiving
::orientation-changed signals, this may result in the display orientation
being effectively rotated, then stay locked after that.
In order to fix this, make the MetaOrientationManager return a fixed
orientation while locked, only updated after changes in the lock state.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2600
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3021>
This is missed, leaving the cursor renderer disconnected from the stage
updates that could trigger further frame callbacks on the cursor, leaving
some clients like Xwayland stuck with cursors.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3025>
It's just closer to reality of an user session.
As per this:
- We need to bump the required CI template to use this feature.
- Use sudo in the actions that require it
- Replace pkexec with sudo (it wouldn't work otherwise)
- Ensure we don't rebuild during install not to break build dir
- Give permission to use /dev/kvm to our user (we do this during the
image creation because we don't have an user when $FDO_DISTRIBUTION_EXEC
happens)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3016>
We already test install as part of other jobs (such as
can-build-gnome-shell) and in general that's wrong because we may
add to the final install path artifacts that are required during tests,
hiding potential issues with meson test when those files are not
installed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3016>
