In certain scenarios, the frame clock needs to handle present feedback
long before the assumed presentation time happens. To avoid scheduling
the next frame to soon, avoid scheduling one if we were presented half a
frame interval within the last expected presentation time.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
This adds a current unused, apart from tests, frame clock. It just
reschedules given a refresh rate, based on presentation time feedback.
The aiming for it is to be used with a single frame listener (stage
views) that will notify when a frame is presented. It does not aim to
handle multiple frame listeners, instead, it's assumed that different
frame listeners will use their own frame clocks.
Also add a test that verifies that the basic functionality works.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
When a transition is created for the allocation change, it will delay
the new allocation box getting set depending on transition details.
This, however, means that e.g. the 'needs_allocation' flag never gets
cleared if a transition is created, causing other parts of the code to
get confused thinking it didn't pass through a layout step before paint.
Fix this by calling clutter_actor_allocate_internal() with the current
allocation box if a transition was created, so that we'll properly clear
'needs_allocation' flag.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1345
Since we now have the neccessary infrastructure to get notified about
changes to the absolute transformation matrix, we can also invalidate
the stage-views list on updates to this matrix.
So rename absolute_allocation_changed() to absolute_geometry_changed()
to make it clear this function is not only about allocations, and call
that function recursively for all children on changes to the
transformation matrix, too.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1343
If we want to invalidate the stage-views list reliably on changes to the
actors transformation matrices, we also need to get notified about
changes to the custom transformations applied using the
apply_transform() vfunc.
So provide a new API that allows invalidating the transformation matrix
for actors implementing custom transformations, too. This in turn allows
us to cache the matrix applied using the apply_transform() vfunc by
moving responsibility of keeping track of the caching from
clutter_actor_real_apply_transform() to
_clutter_actor_apply_modelview_transform().
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1343
For ClutterText, the resource scale the text is drawn with affects the
size of the allocation: ClutterText will choose a font scale based on
the resource scale, and that font scale can lead to a slight difference
in size compared to the unscaled font.
We currently handle that by queuing a relayout inside the
"resource-scale-changed" signal handler. This solution is a bit
problematic though since it will take one more allocation cycle until
the allocation is actually updated after a scale-change, so the actor is
painted using the wrong allocation for one frame.
Also the current solution can lead to relayout loops in a few cases, for
example if a ClutterText is located near the edge on a 1x scaled monitor
and is moved to intersect a 2x scaled monitor: Now the resource scale
will change to 2 and a new allocation box is calculated; if this
allocation box is slightly smaller than the old one because of the new
font scale, the allocation won't intersect the 2x scaled monitor again
and the resource scale switches back to 1. Now the allocation gets
larger again and intersects the 2x scaled monitor again.
This commit introduces a way to properly support those actors: In case
an actors resource scale might affect its allocation, it should call the
private function clutter_actor_queue_immediate_relayout(). This will
make sure the actor gets a relayout before the upcoming paint happens
afte every resource scale change. Also potential relayout loops can
be handled by the actors themselves using a "phase" argument that's
passed to implementations of the calculate_resource_scale() vfunc.
The new API is private because resource scales are not meant to be used
in a way where the scale affects the allocation. With ClutterText and
the current behavior of Pango, that can't be avoid though, so we need it
anyway.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1276
Since we now always return a resource scale, we can remove the boolean
return value from clutter_actor_get_resource_scale() and
_clutter_actor_get_real_resource_scale(), and instead simply return the
scale.
While at it, also remove the underscore from the
_clutter_actor_get_real_resource_scale() private API.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1276
Now that ClutterActor has a convenient API for getting the stage views
an actor is presented on, we can remove a large part of the code for
resource-scale calculation and instead rely on the stage-views list.
The way this works is a bit different from the old resource scales:
clutter_actor_get_resource_scale() always returns a scale, but this
value is only guaranteed to be correct when called from a vfunc_paint()
implementation, in all other cases the value is guessed using the scale
of the parent actor or the last valid scale. Now in case the value
previously reported by clutter_actor_get_resource_scale() turns out to
be wrong, "resource-scale-changed" will be emitted before the next paint
and the actor has a chance to update its resources.
The general idea behind this new implementation is for actors which only
need the scale during painting to continue using
clutter_actor_get_resource_scale() as they do right now, and for actors
which need the resource scale on other occasions, like during size
negotiation, to use the scale reported by
clutter_actor_get_resource_scale() but also listen to the
"resource-scale-changed" signal to eventually redo the work using the
correct scale.
The "guessing" of the scale is done with the intention of always giving
actors a scale to work with so they don't have to fall back to a scale
value the actor itself has to define, and also with the intention of
emitting the "resource-scale-changed" signal as rarely as possible, so
that when an actor is newly created, it won't have to load its resources
multiple times.
The big advantage this has over the old resource scales is that it's now
safe to call clutter_actor_get_resource_scale() from everywhere (before,
calling it from size negotiation functions would usually fail). It will
also make it a lot easier to use the resource scale for complex cases
like ClutterText without risking to get into relayout loops.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1276
Add private API to ClutterBackend to set a fallback resource scale
available to Clutter. This API will be used for "guessing" the
resource-scale of ClutterActors in case the actor is not attached to a
stage or not properly positioned yet.
We set this value from inside mutters MetaRenderer while creating new
stage-views for each logical monitor. This makes it possible to set the
fallback scale to the scale of the primary monitor, which is the monitor
where most ClutterActors are going to be positioned.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1276
We're going to refactor resource scales, making the notification of
changes to the resource scale a lot more important than it is right now
(we won't guarantee queried scales are correct outside the paint cycle
anymore).
Having a separate signal/vfunc for this will make the difference between
the new clutter_actor_get_resource_scale() API (which can return a
guessed value) and the notification of changes to the resource scale
(which will be guaranteed to return an up-to-date value) more obvious.
So replace the "resource-scale" property of ClutterActor with a
"resource-scale-changed" signal that's emitted when the resource scale
is recalculated.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1276
ClutterBoxLayout calculates the preferred size of the opposite
orientation (so for example the height if the orientation is horizontal)
by getting the preferred size of the real orientation first, and then
the preferred size of the opposite orientation, using the other size as
for_width/height when doing the request.
Right now, for non-homogeneous layouts this for_width/height does not
adjust for the spacing set on the box layout. This leads to children
being passed a slightly larger for_width/height, which in case of
ClutterText might cause the line to not wrap when it actually should.
This in turn means we can end up with an incorrect preferred size for
the opposite orientation, leading to a wrong allocation.
So fix that and adjust for the spacing just as we do for homogeneous
layouts by subtracting the total spacing from the available size that is
distributed between children.
This fixes the wrong height of the checkbox label reported in
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2574.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1333
The property is deprecated and the current implementation simply
redirects it to ClutterActor::background-color, so remove it.
Also update the tests to set the background color directly.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1332
ClutterStage is the one and only subclass of ClutterGroup, but
it overrides basically everything specific to ClutterGroup to
mimic a ClutterActor. What a waste!
Subclass ClutterActor directly and remove all the now useless
vfunc overrides from ClutterStage. Adapt CallyStage to subclass
CallyActor as well.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1332
It is deprecated in favor of the 'z-position' property, and
the implementation itself redirects to the z-position, so
just drop it and replace all get|set_depth calls to their
z-position counterparts.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1332
I noticed my system would fall back to the slow unclipped (and
uncullable) paint path whenever a window touched the left edge of
the screen. Turns out that was a red herring. Just that
`use_clipped_redraw` was uninitialized so clipping/culling was used
randomly.
So the compiler failed to notice `use_clipped_redraw` was uninitialized.
Weirdly, as soon as you fix that it starts complaining that `buffer_age`
might be uninitialized, which appears to be wrong. So we initialize that
too, to shut up the compiler warnings/errors.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1323
The ClutterBindConstraint will change the preferred size an actor
reports so it returns the same size as the source actor in some cases.
This behavior was introduced recently with 4f8e518d.
This can lead to infinite loops in case the source actor is a parent of
the actor the BindConstraint is attached to, that's because calling
get_preferred_size() on the source will recursively call
get_preferred_size() on the actor again.
So to avoid those loops, check if the source is a parent of the actor
we're attached to and don't update the preferred size in that case.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1282
For ClutterClones we need to apply a scale to the texture of the clone
to ensure the painted texture of the source actor actually fits the
allocation of the clone. We're doing this using the transformation
matrix instead of using the scale_x/scale_y properties of ClutterActor
to allow users to scale ClutterClones using that API independently.
Now it's quite a bad idea to get the allocation boxes for calculating
that scale using clutter_actor_get_allocation_box(), since that method
will internally do an immediate relayout of the stage in case the actor
isn't allocated. Another side effect of that approach is that it makes
it impossible to invalidate the transform (which will be needed when we
start caching those matrices) properly.
So since we eventually allocate both the source actor and the clone
ourselves anyway, we can simply use the allocation box inside
clutter_clone_allocate() (which is definitely updated and valid at that
point) to calculate the scale factor.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1181
It seems wrong to use the scale factor of the X axis on the Z axis and
it looks like this has been accidentally changed in commit 570fa3f044.
So use a factor of 1.0 instead to not scale the Z axis at all because
the layout machinery only works in X and Y coordinates.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1181
There are cases where a layout manager used by an actor also wants to
return a custom size when the actor has no children, for example in case
the layout manager requests a fixed size. This is currently impossible
because we only query the layout manager when calculating the preferred
size if the actor has children.
So fix that and also use the layout managers size negotiation functions
in case the actor has no children.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1322
The size of the buffer the texture will be written to by
paint_to_buffer() is determined based on
meta_screen_cast_area_stream_src_get_specs() which uses roundf() to
calculate the width and height after scaling. Because the size of the
texture to be written to that buffer is calculated using ceilf(), it
might exceed the allocated buffer when using fractional scaling.
In 3.36 paint_to_buffer() is used from capture_view() which also uses
roundf() to allocate its buffer. Here this leads to a memory corruption
resulting in a crash when taking screenshots of an area.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2842https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1320
The modifier state of the input device is supposed to be set to the
newest state, while the modifier state detail of the event is set to the
last state before the event (so not including the changes triggered by
the event).
So since the modifier state of the event is the last state anyway, the
state of the ClutterInputDevice is supposed to be set by the backend and
not by the stage while queuing the event, so stop setting the state
here.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1275
Make the clutter_input_device_get_actor() API public and remove
clutter_input_device_get_pointer_actor() in favour of the new function.
This allows also getting the "pointer" actor for a given touch sequence,
not only for real pointer input devices like mice.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1275
Switch from clutter_seat_list_devices() to the new peek_devices() method
of ClutterSeat in cases where we're only looping through the returned
list without manipulating it. This way we don't have to unnecessarily
copy around the list of devices.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1275
Add a method to ClutterSeat that allows peeking the list of input
devices and allow looping through devices a bit faster. The API left is
private so we can make use of peeking the GList internally, but don't
have to expose any details to the outside, which means we'd have to
eventually stick with a GList forever to avoid breaking API.
Since we now have the peek_devices() API internally, we can implement
ClutterSeats public list_devices() API using g_list_copy() on the list
returned by peek_devices().
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1275
While it's strongly discouraged, it is possible to queue a new relayout
of an actor in the middle of an allocation cycle, we warn about it but
don't forbid it.
With the introduction of the "shallow relayout" API, our handling of
those relayouts silently changed: Before introducing "shallow
relayouts", we'd handle them on the next stage update, but with the
priv->pending_relayouts hashtable and the
priv->pending_relayouts_version counter, we now do them immediately
during the same allocation cycle (the counter is increased by 1 when
queuing the relayout and we switch to a new GHashTableIter after
finishing the current relayout, which means we'll now do the newly
queued relayout).
This change in behavior was probably not intended and wasn't mentioned
in the commit message of 5257c6ecc2, so
switch back to the old behavior, which is more robust in preventing
allocation-loops. To do this, use a GSList instead of GHashTable for the
pending_relayouts list, and simply steal that list before doing the
relayouts in _clutter_stage_maybe_relayout().
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1267
ClutterAlignConstraint currently assumes the source actor is positioned
in the same coordinate system as the actor it's attached to and
automatically offsets the adjusted allocation by the origin of the
source actor.
This behavior is only valid though in case the source actor is a sibling
of the constraint actor. If the source actor is somewhere else in the
actor tree, the behavior gets annoying because the constraint actor is
offset by (seemingly) random positions.
To fix this, stop offsetting the constraint actors allocation by the
position of the source.
To still make it possible to align the constraint actors origin with the
origin of the source, no longer override the origin of the allocation
in the AlignConstraint. This allows users to align the origin using a
BindConstraint, binding the actor position to the position of the
source, which is more flexible and also more elegant.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/737
Add a new pivot-point property to the ClutterAlignConstraint, similar to
the pivot point used by ClutterActor, defining the point in the
constraint actor around which the aligning is applied to the actor.
Just as the ClutterActor property, this property is defined using a
GraphenePoint.
By default this property remains set to (-1, -1) and the actor
will always be aligned inside the source actor, preserving the existing
behavior of ClutterAlignConstraint.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/737
Now that we have a proper way to mark our allocation as uninitialized,
make use of that and only disallow implicit transitions of the
"allocation" property if that is the case.
This fixes a bug where easing the allocation of an actor is impossible
when someone queued a relayout on it (or a child of it) before.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1290
We currently initialize the ClutterActorBox of the actors allocation to
zero, but there's a difference between a valid zero-allocation and an
actor having never been allocated. Currently it's impossible for us to
detect the latter case in a reliable way and we use the needs_allocation
flag for this, which may also be set in other situations.
So initialize the allocation of actors to the newly added UNINITIALIZED
ClutterActorBox, which will make it easier to detect whether an actor
already got its initial allocation.
This also fixes another issue right now: Actors which get allocated a
(valid) zero allocation, will now notify the "allocation" property in
this case.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1290
Add support for an artificial UNINITIALIZED marking for ClutterActorBox,
done by setting the boxes origin to Infinity and its size to -Infinity.
That is a value that's considered an invalid allocation by Clutter and
which can never be set by sane code.
This will allow setting the allocation of ClutterActors to an
UNINITIALIZED box when creating actors or when removing them from the
scenegraph and makes it possible to explicitely detect uninitialized
allocations, which is useful in a few cases.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1290
We currently go through the whole tree of mapped actors on every paint
cycle to update the stage views actors are on. Even if no actors need
updating of their stage views, traversing the actor tree is still quite
expensive and shows up when using a profiler.
So tone down the amounts of full-tree traversals we have to do on every
paint cycle and only traverse a subtree if it includes an actor which
actually needs updating of its stage views.
We do that by setting the `needs_update_stage_views` flag to TRUE
recursively for all parents up to the stage when the stage-views list of
an actor gets invalidated. This way we end up updating a few more actors
than necessary, but can avoid searching the whole actor tree for actors
which have `needs_update_stage_views` set to TRUE.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1196
Add a new signal that's emitted when the stage views an actor being
painted on have changed, "stage-views-changed". For example this signal
can be helpful when tracking whether an actor is painted on multiple
stage views or only one.
Since we must clear the stage-views list when an actor leaves the stage
(actors that aren't attached to a stage don't get notified about the
stage views being changed/replaced), we also emit the new signal when an
actor gets detached from the stage (otherwise there would be an edge
case where no signal is emitted but it really should: An actor is
visible on a stage view, then detached from the stage, and then attached
again and immeditely moved outside the view).
Also skip the comparison of the old stage-views list and the new one if
nobody is listening to the signal to save some resources.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1196
There are certain rendering techniques and optimizations, for example
the unredirection of non-fullscreen windows, where information about the
output/stage-view an actor is on is needed to determine whether the
optimization can be enabled.
So add a new method to ClutterActor that allows listing the stage-views
the actor is being painted on: clutter_actor_peek_stage_views()
With the way Clutter works, the only point where we can reliably get
this information is during or right before the paint phase, when the
layout phase of the stage has been completed and no more changes to the
actors transformation matrices happen. So to get the stage views the
actor is on, introduce a new step that's done on every master clock tick
between layout and paint cycle: Traversing through the actor tree and
updating the stage-views the mapped actors are going to be painted on.
We're doing this in a separate step instead of inside
clutter_actor_paint() itself for a few reasons: It keeps the code
separate from the painting code, making profiling easier and issues
easier to track down (hopefully), it allows for a new
"stage-views-changed" signal that doesn't interfere with painting, and
finally, it will make it very easy to update the resource scales in the
same step in the future.
Currently, this list is only invalidated on allocation changes of
actors, but not on changes to the transformation matrices. That's
because there's no proper API to invalidate the transformation matrices
ClutterActor implementations can apply through the apply_transform()
vfunc.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1196
When the stage views the stage is shown on are changed, ClutterStage
currently provides a clutter_stage_update_resource_scales() method
that allows invalidating the resource scales of all actors. With the new
stage-views API that's going to be added to ClutterActor, we also need a
method to invalidate the stage-views lists of actors in case the stage
views are rebuilt and fortunately we can re-use the infrastructure for
invalidating resource scales for that.
So since resource scales depend on the stage views an actor is on,
rename clutter_stage_update_resource_scales() and related methods to
clutter_stage_clear_stage_views(), which also covers resource scales.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1196
While the layout manager of a ClutterActor does get properly unset when
destroying an actor, we currently forget to disconnect the
"layout-changed" signal from it.
So do that, and while at it, also switch to using the signal id for
disconnecting from the signal instead of
g_signal_handlers_disconnect_by_func(), which caused problems before
because it might traverse the signal handler list.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1281
We currently are confusing g_param_spec_enum and g_param_spec_flags for
the offscreen-redirect property of ClutterActor. Since it's actually a
flag, make it a flag everywhere.
Fun fact: This was already partly done with
d7814cf63e, but that commit missed the
setter.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1292
Just like the ClutterBindConstraint, the ClutterAlignConstraint should
listen to "queue-relayout" of its source actor, not
"notify::allocation". That's because the latter will queue a relayout
during an allocation cycle and might cause relayout loops.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1296
Hiding a compositor stage is not something that's really supported, but
will still be used by tests, to get closer to a "fresh" stage for each
test case, when the tests eventually start using the mutter provided
stage.
It'll use that stage simply because creating standalone stages isn't
supported.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1289
The script parser only included G_PARAM_CONSTRUCT_ONLY parameters when
constructing objects. This causes issues if an object requires a
parameter to be set during construction, but may also change after. Fix
this by including G_PARAM_CONSTRUCT parameters when constructing script
objects as well.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1289
Start follow the convention used in ClutterFrameClock by including the
meaning as well as time granularity in the variable name. The
constructor takes the intended duration of the constructed timeline in
milli seconds, so call the constructor argument `duration_ms`. This is
done in preparation for adding more constuctors.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1289
For actors which don't have needs_allocation set to TRUE and where the
new allocation wouldn't be different from the old one, the allocate()
vfunc doesn't have to be called. We still did this in case a parent
actor was moved though (so the absolute origin changed), because we
needed to propagate the ABSOLUTE_ORIGIN_CHANGED allocation flag down to
all actors.
Since that flag is now removed and got replaced with a private property,
we can simply notify the children about the absolute allocation change
using the existing infrastructure and safely stop allocating children at
this point.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1247
With commit 0eab73dc2e we introduced an optimization of not doing
allocations for actors which are hidden. This broke the propagation of
absolute origin changes to hidden actors, so if an actor is moved while
its child is hidden, the child will not get
priv->needs_compute_resource_scale set to TRUE, which means the resource
scale won't be updated when the child gets mapped and shown again.
Since we now have priv->absolute_origin_changed, we can simply check
whether that is TRUE for our parent before bailing out of
clutter_actor_allocate() and if it is, notify the whole hidden sub-tree
about the absolute origin change.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1247
Since clutter_stage_set_viewport() is only used inside clutter-stage.c
anyway, we can make it a static method. Also we can remove the x and y
arguments from it since they're always set to 0 anyway.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1247
When getting the last allocation using
clutter_actor_get_allocation_box(), Clutter will do an immediate
relayout of the stage in case an actor has an invalid allocation. Since
the allocation is always invalid when the allocate() vfunc is called,
clutter_stage_allocate() always forces another allocation cycle.
To fix that, stop comparing the old allocation to the new one to find
out whether the viewport changed, but instead use the existing check in
_clutter_stage_set_viewport() and implement the behavior of rounding the
viewport to the nearest int using roundf() (which should behave just as
CLUTTER_NEARBYINT()) since we're passing around floats anyway.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1247
When manipulating the allocation of a ClutterActor from an allocate()
vfunc override, clutter_actor_set_allocation() is used to let Clutter
know about the changes.
If the actors allocation or its absolute origin did not change before
that, this can also affect the actors absolute_origin_changed property
used by the children to detect changes to their absolute position.
So fix this bug (which luckily didn't seem to affect us so far) and set
priv->absolute_origin_changed to TRUE in case the origin changes inside
clutter_actor_set_allocation_internal(). Since this function is always
called when our allocation changes, we no longer need to update
absolute_origin_changed in clutter_actor_allocate() now.
Since a change to the absolute origin always affects the resource scale,
too, we also need to move that check from clutter_actor_allocate() here
to make sure we update the resource scale.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1247
Since the introduction of the shallow relayout functionality it's
possible to start an allocation cycle at any point in the tree, not only
at the stage. Now when starting an allocation at an actor that's not the
stage, we'd still look at the absolute_origin_changed property of this
actors parent, which might still be set to TRUE from the parents last
allocation.
So avoid using the parents absolute_origin_changed property from the
last allocation in case a shallow relayout is being done and always
reset the absolute_origin_changed property to FALSE after the allocation
cycle.
This broke with the removal of the ABSOLUTE_ORIGIN_CHANGED
ClutterAllocationFlag that was done in commit dc8e5c7f.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1247
This cannot be made to work reliably. Some factoids:
- Internal devices may be connected via USB.
- The ACPI spec provides the _PLD (Physical location of device) hook to
determine how is an USB device connected, with an anecdotal success
rate. Internal devices may be seen as external and vice-versa, there is
also an "unknown" value that is widely used.
- There may be non-USB keyboards, the old "AT Translated Set 2 Keyboard"
interface does not change on hotplugging.
- Libinput has an internal series of quirks to classify keyboards as
internal of external, also with an "unknown" value.
These heuristics are kinda hopeless to get right by our own hand. Drop
this external keyboard detection in the hope that there will be something
more deterministic to rely on in the future (e.g. the libinput quirks
made available to us directly or indirectly).
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2378
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2353https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1277
In clutter_text_queue_redraw_or_relayout() we check whether the size
of the layout has changed and queue a relayout if it did, otherwise we
only queue a redraw and save some resources.
The current check for this also queues a redraw if the actor has no
valid allocation. That seems right on the first glance since the actor
will be allocated anyway, but we actually want to call
clutter_actor_queue_relayout() again here because that also invalidates
the size cache of the actor which might have been updated and marked
valid in the meantime.
So make sure the size cache is always properly invalidated after the
size of the layout changed and also call clutter_actor_queue_relayout()
in case the actor has no allocation.
This fixes a bug where getting the preferred width of a non-allocated
ClutterText, then changing the string of the ClutterText, and then
getting the preferred width again would return the old cached width (the
width before we changed the string).
The only place where this bug is currently happening is in the overview,
where we call get_preferred_width() on the unallocated ClutterText of
the window clone title: When the window title changes while the
ClutterText is unallocated the size of the title is going to be wrong
and the text might end up ellipsized or too large.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1150
It's effectively used by mutter by abusing a ClutterTimeline to scedule
updates. Timelines are not really suited in places that is done, as it
is really just about getting a single new update scheduled whenever
suitable, so expose the API so we can use it directly.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1218
We could call clutter_stage_schedule_update() and it wouldn't actually
schedule anything, as the master frame clock only tries to reschedule if
1) there is an active timeline, 2) there are pending relayouts, 3) there
are pending redraws, or 4) there are pending events. Thus, a call to
clutter_stage_schedule_update() didn't have any effect if it was called
at the wrong time.
Fix this by adding a boolean state "needs_update" to the stage, set on
clutter_stage_schedule_update() and cleared on
_clutter_stage_do_update(), that will make the master clock reschedule
an update if it is TRUE.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1218
We need to use the framebuffer of the view instead of the onscreen
framebuffer when painting the damage region, otherwise the redraw clips
on rotated monitors won't be shown correctly.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1237
Compare, tile by tile, whether actual damage actually changed any
pixels. While this requires mmap():ing DMA buffers and comparing their
content, we should only ever use shadow buffers when we're using the
software renderer, meaning mmap() is cheap as it doesn't involve any
downloading.
This works by making the shadow framebuffer double buffered, while
keeping track of damage history. When we're about to swap the onscreen
buffer, we compare what part of the posted damage actually changed,
records that into a damage history, then given the onscreen buffer age,
collect all actual damage for that age. The intersection of these tiles,
and the actual damage, is then used when blitting the shadow buffer to
the onscreen framebuffer.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1157https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1237
Move the damage history tracking to a new ClutterDamageHistory helper
type. The aim is to be able to track damage history elsewhere without
reimplementing the data structure and tracking logic.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1237
This fixes the last "copy everything" paths when clutter doesn't
directly paint onto the onscreen framebuffer. It adds a new hook into
the stage view called before the swap buffer, as at this point, we have
the swap buffer damag regions ready, which corresponds to the regions we
must blit according to the damage reported to clutter.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1237
The rest didn't change, so only actually paint the part of the offscreen
that was composited as part of the stage painting. In practice, this
means that, unless a shadow buffer is used, we now only paint the
damaged part of the stage, and copy the damage part of the offscreen to
the onscreen.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1237
We failed to use the buffer age when monitors were rotated, as when they
are, we first composite to an offscreen framebuffer, then later again to
the onscreen. The buffer age checking happened on the offscreen, and an
offscreen being single buffered, they can't possible support buffer
ages.
Instead, move the buffer age check to check the actual onscreen
framebuffer. The offscreen to onscreen painting is still always full
frame, but that will be fixed in a later commit.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1237
The manual "cleaning" of the viewport and projection state is removed,
and we only ever try to invalidate the state so that it'll be updated
next time. Change the API used to reflect this.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1237
The stage would fetch the front framebuffer and set the viewport and
projection matrix, but if we are going to more than one front buffer,
that won't work, so let the stage just pass the viewport and projection
matrix to the view and have the view deal with the framebuffer(s).
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1237
Will be used for logging to identify what view a log entry concerns. For
the native and nested backend this is the name of the output the CRTC is
assigned to drive; for X11 it's just "X11 screen", and for the legacy
"X11 screen" emulation mode of the nested backend it's called "legacy
nested".
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1237
All existing users of clutter_actor_has_mapped_clones() actually want to
know whether the actor is being cloned by a visible clone, it doesn't
matter to them if that clone is attached to an actor somewhere else in
the tree or to the actor itself.
So make clutter_actor_has_mapped_clones() a bit more convenient to use
and also check the clones of the parent-actors in that function.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1235
The comment in _clutter_actor_get_allocation_clip() explicitely notices
that it doesn't need the behavior of doing an immediate relayout as
clutter_actor_get_allocation_box() does. The comment is also still valid
since the code calling _clutter_actor_get_allocation_clip() checks for
priv->needs_allocation just before.
So let's just use the allocation directly here instead of going through
that function.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1264
ClutterBoxLayout's layout policy of using the generic ClutterActor
align/expand properties for children that are expanded and a custom
meta otherwise is confusing, in particular as the x-fill/y-fill
defaults don't match the default CLUTTER_ACTOR_ALIGN_FILL align.
StBoxLayout's own custom child meta (which was deprecated last
cycle) is probably the only consumer. And luckily, the St meta
uses different x-fill/y-fill default that match the ClutterActor
defaults, so removing it will not affect code that doesn't use
the deprecated properties themselves.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1265
This stuff has been deprecated for a very long time, and given that
ClutterBoxLayout is most commonly used via StBoxLayout, the impact of
removing it should be low. It will however open the door to further
cleanups.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1265
We're going to remove the "allocation-changed" signal from ClutterActor
since it's no longer needed now that ClutterAllocationFlags are gone.
So listen to "notify-allocation" instead, which has been the recommended
thing to do for some time now anyway.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1245
The ABSOLUTE_ORIGIN_CHANGED allocation flag is only really useful to
propagate the information of the absolute origin of an actor having
changed inside Clutter. It wasn't used anywhere else besides for some
debug messages and it probably shouldn't be used in custom layout
implementations anyway since 1) actors shouldn't have to be aware of
absolute allocation changes and 2) it doesn't factor in changes to the
transformation matrix of a parent.
Also the propagation of absolute origin changes using this flag broke
with commit 0eab73dc2e and now hidden actors are no longer notified
about those changes.
Additionally, this flag gets in the way of a few potential optimizations
since it has to be propagated even if the allocation box of the child
hasn't changed, forcing a reallocation of the child.
So replace this flag with a simple new private property of ClutterActor
absolute_origin_changed, but keep the exact same behavior for now.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1245
Since we now only layout the children ourselves in case the actor
implementation doesn't override the allocate vfunc, we can remove
clutter_actor_maybe_layout_children() and move the functionality inside
clutter_actor_real_allocate().
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1245
Now that we no longer have the DELEGATE_LAYOUT we expect all actors
overriding the allocate() vfunc to allocate their children themselves.
Since clutter_actor_set_allocation() is only called from custom
vfunc_allocate() implementations, the condition in
clutter_actor_maybe_layout_children() would always fail, which makes
calling the function useless anyway.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1245
The CLUTTER_DELEGATE_LAYOUT flag is unintuitive and makes the allocation
process inside Clutter unnecessarily complicated. It's very easy for
actors overriding the allocate() vfunc to layout their children
themselves (in fact most of them do this), and it also never made sense
that clutter_actor_set_allocation() does eventually layout children.
There was no ClutterActor implementation in mutter or gnome-shell which
actually used the DELEGATE_LAYOUT flag, but even without it, it's fairly
easy to archive the same behavior now: In the allocate() override,
adjust the allocation as wanted, then chain up to the parent vfunc
without calling clutter_actor_set_allocation().
So remove the CLUTTER_DELEGATE_LAYOUT flag, which will allow making the
relayout code in Clutter a bit easier to follow.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1245
We're going to remove allocation flags, so stop depending on the
DELEGATE_LAYOUT flag in ClutterStage and call
clutter_layout_manager_allocate() directly, which is pretty
straightforward.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1245
The public API to get the parent actor, clutter_actor_get_parent() does
a type check whether the actor is actually a ClutterActor. In case of
_clutter_actor_apply_relative_transformation_matrix(), which is called
recursively and very often during the paint process, this type check
shows up with almost twice the amount of hits than the actual matrix
multiplication.
So use the parent pointer directly in some code paths that are executed
very often and avoid the expensive type checking there, we can do that
since both places are not public API.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1259
Reverting the scale and offset applied to the damage history can be done
in one step, using a few less temporary allocations by passing the
offset right away to a new scale_offset_and_clamp_region() function.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1113
Since the damage history region is tracked per-view, all the regions it
includes should be inside the current view anyway, so don't
unnecessarily intersect that region with the view.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1113
Since we now check for the buffer age before setting up the
fb_clip_region, that region will be set to the full extents of the view
in case the buffer age is invalid. This in turn means we don't have to
do this again later and can simply fill the damage history with the
fb_clip_region that's already set for us.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1113
Since a NULL redraw_clip means that a full view redraw should be done
and an empty redraw clip may never be set (see the width/height checks
in clutter_stage_view_add_redraw_clip()), the fb_clip_region should
always be set to a reasonable region that's either the whole view or
individual regions inside the view.
So make sure that's actually the case by warning and that the
fb_clip_region isn't empty, which allows dropping another few lines of
code.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1113
Right now we're checking for the DISABLE_CLIPPED_REDRAWS debug flag
after creating the fb_clip_region and adjusting the redraw_clip. That
means that if may_use_clipped_redraw was TRUE, the redraw_clip will
still be set to the region and thus cause the stage to only be partially
redrawn. Since we don't push a clip to the framebuffer though
(use_clipped_redraw is now FALSE), parts of the view will get corrupted.
To fix that, disable clipped redraws right away if the debug flag is
set. This also allows removing the may_use_clipped_redraw bool and
replacing it entirely with use_clipped_redraw.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1113
We already have a better way to paint the redraw clip: Painting the
damage region paints the individual rects of the clip region and not
only the bounding rect.
So stop painting an outline around the redraw clip bounding rect when
CLUTTER_DEBUG_REDRAWS is set.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1113
While this is meant as an optimzation to only use the scissor clip and
not the stencil buffer if there's only one clip rectangle, it's not
needed since this optimization is going to be applied to region clips
anyway inside _cogl_clip_stack_gl_flush() (see cogl-clip-stack-gl.c).
So remove the unnecessary optimization here and rely on cogl-clip-stack
to do it for us.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1113
This was introduced with commit 9ab338d7b6 because the clipping of
fractionally scaled redraws caused glitches, it seems like this is no
longer needed nowadays, so let's remove it.
This should make obscured region culling work a bit better for
fractionally scaled framebuffers because because we overdraw a slightly
smaller region than the actually damaged one. We still do overdraw
though since the clipping region is stored using integers and thus
any non-integer values have to be extended to the bounding rect.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1113
It doesn't make sense to set the redraw clip when painting the stage if
clipped redraws are disabled. That's because when visualizing the redraw
clip and any new redraws are clipped, the old visualiziations would
remain visible, leaving multiple confusing rectangles on the screen.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1113
This removes ClutterAnimation and related tests. ClutterAnimation has
been deprecated for a long time, and replacements exist and are used by
e.g. GNOME Shell since a while back.
This also disables a few relatively unrelated interactive tests, as they
rely on ClutterAnimation to implement some animations they use to
illustrate what they actually test.
As interactive tests currently are more or less untestable due to any
interaction with them crashing, as well as they in practice means
rewriting the tests using non-deprecated animation APIs, they are not
ported right now. To actually port the interactive tests, it needs to be
possible to fist interact with them.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1192
In the past, it was a odd mix of possible different types, all coalesced
into an unsigned integer. Now, hovewer, it's always a
ClutterAnimationType, so lets change the name of getter, setter and
property to what it really is.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1192
The CLUTTER_ACTOR_IN_REPARENT and the CLUTTER_IN_REPARENT flag are never
set and the logic for skipping unmap, unrealize and the emission of the
"parent-set" signal during reparents has been solved differently by
leaving out the CHECK_STATE and EMIT_PARENT_SET flags when calling
add_child_internal() and remove_child_internal().
The only place where those REPARENT flags are theoretically still useful
is in the clutter_actor_verify_map_state() debugging function, but that
is never called during reparent anyway, so simply leave the comment
regarding reparent there.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1228
The redraw clip that's painted together with the damage region has to be
copied earlier than we do right now. That's because if
PAINT_DAMAGE_REGION is enabled, buffer age is disabled and thus
use_clipped_redraw is FALSE. That means the redraw_clip is updated and
set to the full view-rect. If we copy the queued_redraw_clip after that,
it's also going to be set to the full view-rect. So copy the redraw clip
a bit earlier to make sure we're actually passing the real redraw clip
to paint_damage_region().
Also keep the queued_redraw_clip around a bit longer so it can actually
be used by paint_damage_region() and isn't freed before that.
While at it, move paint_damage_region() from swap_framebuffer() into
clutter_stage_cogl_redraw_view() so we don't have to pass things to
swap_framebuffer() only for debugging.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1104https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1208
It takes coordinates in stage coordinate space, and will result in
a screen cast stream consisting of that area, but scaled up by the scale
factor of the view that overlaps with the area and has the highest scale
factor.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1207
Will be used by the stage to not paint the overlays. We skip all
overlays since overlays are only ever used for pointer cursors when the
hardware cursors cannot or should not be used.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1207
Either onto a framebuffer, or into a CPU memory buffer. The latter will
use an former API and then copy the result to CPU memory. The former
allocates an offscreen framebuffer, sets up the relevant framebuffer
matrices and paints part of the stage defined by the passed rectangle.
This will be used by a RecordArea screen cast API. The former to paint
directly onto PipeWire handled dma-buf framebuffers, and the latter for
PipeWire handled shared memory buffers.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1207
A paint flag affects a paint operation in ways defined by the flags.
Currently no flags are defined, so no semantical changes are defined
yet. Eventually a flag aiming to avoid painting of cursors is going to
be added, so that screen cast streams can decide whether to include a
cursor or not.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1207
Try to bypass compositing if there is a fullscreen toplevel window with
a buffer compatible with the primary plane of the monitor it is
fullscreen on. Only non-mirrored is currently supported; as well as
fullscreened on a single monitor. It should be possible to extend with
more cases, but this starts small.
It does this by introducing a new MetaCompositor sub type
MetaCompositorNative specific to the native backend, which derives from
MetaCompositorServer, containing functionality only relevant for when
running on top of the native backend.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
Make it possible to cause the next frame to scan out directly from the
passed CoglScannout. This makes it possible to completely bypass
compositing for the following frame.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
Transitions are used for animating actors when e.g. going from/to
fullscreen, and the like. We need to know such things when deciding
whether to avoid compositing a window actor, so make add API visible to
mutter that checks whether there are any transitions active.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
click_action_query_long_press() can potentially schedule more than
one timeout, since it doesn't clear any already-existing timeout.
Make sure to clear the long press timeout before scheduling a new
one.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1188
Like the click action, it makes sense to cancel the ongoing gesture
when the action is disabled. Do so by overriding our new friend,
ClutterActorMeta.set_enabled, and canceling the gesture when disabling
the action.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1188
ClutterClickAction, like other actions, can potentially be disabled
at any time (that is not during painting). When that happens with
ClutterClickAction, it must release all timeouts and disconnect from
the stage's 'capture-event'.
Override ClutterActorMeta.set_enabled and release the click action
when the action is being disabled.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1188
Various subclasses of ClutterActorMeta need to reacto to being
disabled. Right now, however, the only way to do that is by
overriding GObject's 'notify' vfunc, and doing a string comparison
against "enabled".
Add a new vfunc to ClutterActorMeta in order to replace this bad
practice.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1187
In the unlikely case we have multiple rectangles in our selection
(selection spanning several lines, or across LTR/RTL bounds), paint each
of those instead of setting a CoglPath-based clip/fill.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1126
With the introduction of "shallow" relayouts, we are now able to enter
allocation cycles not only at the stage but also deeper down the
hierarchy if we know an actors allocation isn't affected by its children
since the NO_LAYOUT flag is set.
Now that means when queuing relayouts it's possible that
`priv->needs_allocation` gets set to TRUE for some actors down the
hierarchy, but not for actors higher up in the hierarchy. An actor tree
where that happens could look like that:
stage -> container -> container2 (NO_LAYOUT) -> textActor
With that tree, if the "textActor" queues a relayout, "container2" will
be added to the relayout hashtable of the stage and the actors "stage"
and "container" will have `priv->needs_allocation` set to FALSE.
Now if another relayout on the stage actor is queued,
`clutter_stage_queue_actor_relayout()` currently removes all the other
hashtable entries in favour of the stage entry, (wrongly) assuming that
will allocate everything. It doesn't allocate everything because in the
example above "container" has `priv->needs_allocation` set to FALSE,
which makes clutter_actor_allocate() return early before allocating its
children, so in the end "container2" will never get a new allocation.
To fix this, stop flushing the relayout hashtable when queuing a
stage-relayout and still add new entries to the hashtable if a stage
relayout is already queued to make sure we still go through all the
previously queued "shallow" relayouts. That shouldn't hurt performance,
too, because as soon as an actor got allocated once, it doesn't need an
allocation anymore and should bail out in clutter_actor_allocate() as
long as it's absolute position didn't change.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2538https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1173
Disabling a click action after a button-press but before a
button-release is captured makes ClutterClickAction connect to
captured-event and never disconnect.
This change fixes it by making sure the captured-event is only
processed if the action is still enabled, otherwise releasing
the action (reset state) and propagating the event.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1170
Nothing should ever disable an actor modifier (e.g. effect) during the
paint sequence, nor should any actor be set or unset on it. If this
would happen, log warnings so that it can be tracked down.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1166
When selecting the pick regions for an actor we were not considering
whether the actor was allocated and that was causing issues where the
preferred width/height of the actor was used when deciding whether
the actor should be considered as a pick target.
Check if the actor has a valid allocation, in addition to being mapped
and being in pick mode, in clutter_actor_should_pick_paint().
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1169
The input method can assign a negative value to
clutter_input_method_delete_surrounding() to move the cursor to the left.
But Wayland protocol accepts positive values in delete_surrounding() and
GTK converts the values to the negative ones in
text_input_delete_surrounding_text_apply().
https://gitlab.gnome.org/GNOME/mutter/issues/539
Fix a regression that got introduced with
c483b52d24 where we started passing the
redraw_clip to paint_stage() instead of creating a temporary view_region
for unclipped redraws: In case we detect an invalid buffer age, we fall
back to doing an unclipped redraw after we passed the first check
setting up may_use_clipped_redraw. That means we didn't reset the
redraw_clip to the view_rect, and we're now going to redraw the stage
using the original redraw clip even though we're swapping the full
framebuffer without damage.
To fix that, check for the buffer age before setting up the
fb_clip_region and the redraw_clip and set may_use_clipped_redraw to
FALSE if the buffer age is invalid, too. This ensures the redraw_clip is
always going to be correctly set to the view rect when we want to force
a full redraw.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/1128
When calculating the resource scale of a clone source, we might end up
in situations where we fail to do so, even though we're in a paint. A
real world example when this may happen if this happens:
* A client creates a toplevel window
* A client creates a modal dialog for said toplevel window
* Said client commits a buffer to the modal before the toplevel
If GNOME Shell is in overview mode, the window group is hidden, and the
toplevel window actor is hidden. When the clone tries to paint, it fails
to calculate the resource scale, as the parent of the parent (window
group) is not currently mapped. It would have succeeded if only the
clone source was unmapped, as it deals with the unmapped actor painting
by setting intermediate state while painting, but this does not work
when the *parent* of the source is unmapped as well.
Fix this by inheriting the unmapped clone paint even when calculating
the resource scale.
This also adds a test case that mimics the sequence of events otherwise
triggered by a client. We can't add a Wayland client to test this, where
we actually crash is in the offscreen redirect effect used by the window
dimming feature in GNOME Shell.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/808https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1147
This is so that cogl-trace.h can start using things from cogl-macros.h,
and so that it doesn't leak cogl-config.h into the world, while exposing
it to e.g. gnome-shell so that it can make use of it as well. There is
no practical reason why we shouldn't just include cogl-trace.h via
cogl.h as we do with everything else.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1059
This adds a new frameclock tracing mark for a single cycle of the frame
clock. Doing so allows Sysprof to potentially do more with the information
that happens during the frameclock. For example, we can now find
allocations that happen while the frame clock is advancing.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1088
offset_scale_and_clamp_region() creates a new region resulting in
view_damage which at this point is the only thing left pointing to what
originally was fb_damage getting overwritten and being leaked.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1089
The stage window handled the redraw clip in a global manner; this would
interfere if we want to paint views individually as it'd mean
intersecting views (i.e. mirrored monitors) would loose the redraw clip
once the first view was painted. It also is awkward to have a global
state for something that is built up before redrawing, and only really
valid during paint, due to buffer damage history.
This commits removes all redraw clip management from the stage window,
moving it all into the stage views. When a redraw clip is added to the
stage, every affected view will get the same redraw clip added to it,
and eventually when painted, the stage window (ClutterStageCogl) will
retrieve the redraw clip for each view as it repaints them.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1042
Instead of users fetching it via `clutter_stage_get_redraw_clip()`, pass
it via the paint context. This is helpful as it is only valid during a
paint, making it more obvious that it needs to be handled differently
when there is no redraw clip (i.e. we're painting off-screen).
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1042
Add a helper that scales and clamps a region, aimed to be used when
transforming between framebuffer coordinate space and view coordinate
spaces.
This helps readability by moving out the verbose for loops that deals
with the individual rects of a region to the helper, making the logic
where it's used much simpler.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1042
The 'have_clip' variable has repeatedly confused me to meaning that
there is a clip. What it actually means is that the effective clip
covers the whole view; the 'redraw_clip == NULL' meaning full redraw is
an important implementation detail for the context, and makes the
intention of the variable unclear; especially since we will after a
couple of blocks will *always* have a clip, just that it covers the
whole view.
Rename the variable to 'is_full_redraw' and negate the meaning, aiming
to make things a lot more clear.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1042
When calculating the fallback framebuffer clip region, which should be
the region in framebuffer coordinates, we didn't scale the view layout
with the view framebuffer scale, meaning for any other scale than 1,
we'd draw a too small region of the view. Fix this by just using the
size of the framebuffer directly, avoiding any scale dependent
calculation all together.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1042
We'll expect a swap event if any of the view paints resulted in a swap;
make the logic dealing with this clearer by making changing the less
vilible '|| swap_event' postfix with a up front '|=' operator.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1042
Prior to this commit the stage was drawn separately for each logical
monitor. This allowed to draw different parts of the stage with
different transformations, e.g. with a different viewport to implement
HiDPI support.
Go even further and have one view per CRTC. This causes the stage to
e.g. draw two mirrored monitors twice, instead of using the same
framebuffer on both. This enables us to do two things: one is to support
tiled monitors and monitor mirroring using the EGLStreams backend; the
other is that it'll enable us to tie rendering directly to the CRTC it
will render for. It is also a requirement for rendering being affected
by CRTC state, such as gamma.
It'll be possible to still inhibit re-drawing of the same content
twice, but it should be implemented differently, so that it will still
be possible to implement features requiring the CRTC split.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1042
This only needs to be initialized once but is in the hot path of creating
new paint nodes (for which we create many). Instead, do this as part of
the clutter_init() workflow to keep it out of the hot path.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1087
When calculating regions, a lot of temporary allocations are created. For
the array of rects (which is often a short number of them) we can use
stack allocations up to 1 page (256 cairo_rectangle_int_t). For building
a region of rectangles, cairo and pixman are much faster if you have all
of the rectangles up front or else it mallocs quite a bit of temporary
memory.
If we re-use the cairo_rectangle_int_t array we've already allocated (and
preferably on the stack), we can delay the creation of regions until after
the tight loop.
Additionally, it requires fewer allocations to union two cairo_region_t
than to incrementally union the rectangles into the region.
Before (percentages are of total number of allocations)
TOTAL FUNCTION
[ 100.00%] [Everything]
[ 100.00%] [gnome-shell --wayland --display-server]
[ 99.67%] _start
[ 99.67%] __libc_start_main
[ 99.67%] main
[ 98.60%] meta_run
[ 96.90%] g_main_loop_run
[ 96.90%] g_main_context_iterate.isra.0
[ 96.90%] g_main_context_dispatch
[ 90.27%] clutter_clock_dispatch
[ 86.54%] _clutter_stage_do_update
[ 85.00%] clutter_stage_cogl_redraw
[ 84.98%] clutter_stage_cogl_redraw_view
[ 81.09%] cairo_region_union_rectangle
After (overhead has much dropped)
TOTAL FUNCTION
[ 100.00%] [Everything]
[ 99.80%] [gnome-shell --wayland --display-server]
[ 99.48%] _start
[ 99.48%] __libc_start_main
[ 99.48%] main
[ 92.37%] meta_run
[ 81.49%] g_main_loop_run
[ 81.49%] g_main_context_iterate.isra.0
[ 81.43%] g_main_context_dispatch
[ 39.40%] clutter_clock_dispatch
[ 26.93%] _clutter_stage_do_update
[ 25.80%] clutter_stage_cogl_redraw
[ 25.60%] clutter_stage_cogl_redraw_view
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1071
g_signal_emit_by_name() is used to emit signals on ClutterContainer when
actors are removed or added. It happens to do various interface lookups
which are a bit unneccessary and can allocate memory.
Simply using emission wrappers makes all of that go away.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1083
Add API to ClutterSeat that allows inhibiting the unsetting of the
pointer focus surface. This can be useful for drawing custom cursor
textures like the magnifier of gnome-shell does.
In the future this API should also control unsetting of Clutters
focus-actor, not just the focus surface, that's not really needed right
now since we never unset the focus-actor anyway.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1077
Which offscreens actor rendering only in cases where it hasn't changed for
2 frames or more. This avoids the performance penalty of offscreening an
actor whose content is trying to animate at full frame rate. It will
switch automatically.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1069
If the transform matrix is an identity, then positioning wont change and
we can avoid creating the transform node altogether. This is based on
a similar find in GTK today while reducing temporary allocations.
This cuts the number of transforms created in clutter_actor_paint() by
about half under light testing of GNOME Shell from 6.8% to 2.4% of
allocations.
Before:
ALLOCATED TOTAL FUNCTION
[ 20.4 MiB] [ 21.20%] clutter_actor_paint
[ 11.0 MiB] [ 11.45%] clutter_paint_node_paint
[ 6.6 MiB] [ 6.84%] clutter_transform_node_new
[ 2.5 MiB] [ 2.61%] clutter_actor_node_new
After:
ALLOCATED TOTAL FUNCTION
[ 33.4 MiB] [ 24.12%] clutter_actor_paint
[ 26.2 MiB] [ 18.91%] clutter_paint_node_paint
[ 3.4 MiB] [ 2.43%] clutter_actor_node_new
[ 3.3 MiB] [ 2.41%] clutter_transform_node_new
Allocation amounts will have differed due to different amounts of running
time, but the % of allocations has now dropped below
clutter_actor_node_new() which should be expected.
https://gitlab.gnome.org/GNOME/mutter/issues/1056
And the corresponding getter. This property returns FALSE by default
and must be overridden by subclasses. This will allow gnome-shell to
hook up specific behavior that should not happen on mouse+keyboard
setups.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1044
If an actor sets flag `CLUTTER_ACTOR_NO_LAYOUT` then that means it
is (or should be) unaffected by `queue_relayout` calls in its children.
So we can avoid propagating `queue_relayout` all the way up to the stage
and avoid a full stage relayout each time.
But those children whose parent has `CLUTTER_ACTOR_NO_LAYOUT` still need
to be allocated at some point. So we do it at the same point where it
happened before. Only we now queue a *shallow* relayout so the `allocate`
run on the next frame doesn't need to descend the whole actor tree anymore.
Only a subtree and hopefully very small.
For free-floating and top-level actors this provides a measurable
performance benefit. According to Google Profiler, calls to
`_clutter_stage_maybe_relayout` are now so cheap that they no longer show
up in performance profiles.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/575
The private function `_clutter_input_device_update()` is not currently
exported.
This function calls `_clutter_input_device_set_actor()` which updates
the `ClutterActor` under the pointer, so making that function available
outside of Clutter will allow to make sure the pointer device actor is
updated prior to do picking.
Also, now that the functions is exported to the upper layers, drop the
underscore suffix from the function name.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1026
Right now the CONTENT_SIZE request mode for a ClutterActor is only
respected by `clutter_actor_get_preferred_size()`, but not by
`get_preferred_width()` and `get_preferred_height()`. Those simply try
to ask the layout manager and will return [0, 0] for actors without
children. So be consistent and also return the content size in those two
functions.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1019
As recommended by the docs for `g_settings_schema_source_get_default`:
> The returned source may actually consist of multiple schema sources
> from different directories, depending on which directories were given
> in XDG_DATA_DIRS and GSETTINGS_SCHEMA_DIR. For this reason, all lookups
> performed against the default source should probably be done recursively.
Now it's actually found and works again, including subpixel font smoothing.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1447https://gitlab.gnome.org/GNOME/mutter/merge_requests/1017
ClutterActors width and height can be reset to automatically use the
preferred (calculated) value by setting the width or height to -1, so
far this only works by setting it using `clutter_actor_set_width()` or
`clutter_actor_set_height()`, make sure it can also be done using the
"width" and "height" GObject properties.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1018
Some ClutterOffscreenEffect subclasses, such as ClutterBrightnessContrastEffect,
early-return FALSE in pre-paint before chaining up. It's an important optimization
that avoids creating or updating the offscreen framebuffer.
However, if an offscreen framebuffer already exists by the time pre-paint fails,
it will be used *without* repaint the actor over it. That causes an old picture
of the actor to be displayed.
Fix that by always clearing the offscreen framebuffer when pre-paint fails.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/810https://gitlab.gnome.org/GNOME/mutter/merge_requests/992
When changing the 'enabled' property and disabling the offscreen effect,
it doesn't make sense to preserve the offscreen framebuffer. It's not
drawing, after all.
Furthermore, because ClutterOffscreenEffect only checks if the offscreen
framebuffer exists to decide whether or not to redraw, keeping the fbo
alive is a waste of resources.
Clear the offscreen framebuffer when the effect is disabled or enabled.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/810https://gitlab.gnome.org/GNOME/mutter/merge_requests/992
FLT_MIN is the smallest *positive* number above 0 that can be
represented as floating point number. If this is used to initialize the
maximum x/y coordinates of a rectangle, this will always be used if all
x/y coordinates of the rectangle are negative. This means that picking
at 0,0 will always be a hit for such rectangles.
Since mutter creates such a window for server side decorations on X11,
this window will always be picked at 0,0 preventing clicking/hovering
the activities button in gnome-shell at that coordinate.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/893
When rendering on-stage, it might be necessary to push offscreen
framebuffers to the paint context by external consumers, such as
GNOME Shell effects.
Expose clutter_paint_context_push|pop_framebuffer().
https://gitlab.gnome.org/GNOME/mutter/merge_requests/955
They have been deprecated for a long time, and all their uses in clutter
and mutter has been removed. This also removes some no longer needed
legacy state tracking, as they were only ever excercised in certain
circumstances when there was sources (pipelines or materials) on the now
removed source stack.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
Stop using API that uses the implicit Cogl framebuffer stack, (e.g.
cogl_push_matrix()) and replace usage by the corresponding API taking an
explicit framebuffer (e.g. cogl_framebuffer_push_matrix()).
For offscreens etc, the offscreen framebuffer is still pushed to and
popped from the Cogl framebuffer stack, so that paint nodes still draw
to the right framebuffer.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
While we still push and pop to the Cogl framebuffer stack, as so is
still needed to render the actors correctly, don't use the API using the
implicit framebuffer stack ourself in the offscreen effect code.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
clutter_paint_node_get_framebuffer() fell back on
cogl_get_draw_framebuffer() when the root node didn't have a custom
get_framebuffer vfunc. As this relies on deprecated implicit Cogl stack
API, it needs to go away, so handle this in the caller that knows more
about the context.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
Instead of using the intermediate stage state "active framebuffer" to
find the framebuffer a paint eventually targets, use the "base
framebuffer" of the paint context, as this more correctly corresponds to
the end point of a paint. It also means we can then later remove this
intermediate state from the stage.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
Instead of pushing and popping the Cogl framebuffer stack, use the
framebuffer passed around using the pick context. This removes usage of
the deprecated framebuffer stack when picking.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
Rendering off stage we never cull, and previously this was checked by
comparing the "active framebuffer" of the stage, to the current
framebuffer in the cogl stack. Replace this by checking whether the
current paint context is currently drawing on stage or not.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
Just as with painting, add a pick context that carries pick related
temporary state when doing actor picking. It is currently unused, and
will at least at first still carry around a framebuffer to deal track
view transforms etc.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
When painting, actors rely on semi global state tracked by the state to
get various things needed for painting, such as the current draw
framebuffer. Having state hidden in such ways can be very deceiving as
it's hard to follow changes spread out, and adding more and more state
that should be tracked during a paint gets annoying as they will not
change in isolation but one by one in their own places. To do this
better, introduce a paint context that is passed along in paint calls
that contains the necessary state needed during painting.
The paint context implements a framebuffer stack just as Cogl works,
which is currently needed for offscreen rendering used by clutter.
The same context is passed around for paint nodes, contents and effects
as well.
In this commit, the context is only introduced, but not used. It aims to
replace the Cogl framebuffer stack, and will allow actors to know what
view it is currently painted on.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
We do check the clip area as an optimization to know which input devices
might need updating state after a relayout (Assuming that if a device is
under a non-painted area, it's actor beneath didn't change).
Use the clip region for this, and drop the last usage of the clip region
bounds.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/867
This commit was split out from `cleanup: Use g_clear_signal_handler()
where possible` as it fixes an actual signal leak and should therefore
get backported to stable releases.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/940
This is inspired by 98892391d7 where the usage of
`g_signal_handler_disconnect()` without resetting the corresponding
handler id later resulted in a bug. Using `g_clear_signal_handler()`
makes sure we avoid similar bugs and is almost always the better
alternative. We use it for new code, let's clean up the old code to
also use it.
A further benefit is that it can get called even if the passed id is
0, allowing us to remove a lot of now unnessecary checks, and the fact
that `g_clear_signal_handler()` checks for the right type size, forcing us
to clean up all places where we used `guint` instead of `gulong`.
No functional changes intended here and all changes should be trivial,
thus bundled in one big commit.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/940
CallyTexture is an accessibility object associated with ClutterTexture.
ClutterTexture is going away, so prepare by first removing the
accessibility object that would be constructed for it.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/932
clutter_event_get_scroll_finish_flags() should return a ClutterScrollFinishFlags
but due to what looks like a bad copy/paste it instead returns a
ClutterScrollSource on asserts.
The definitions of the enums are these:
typedef enum
{
CLUTTER_SCROLL_SOURCE_UNKNOWN,
CLUTTER_SCROLL_SOURCE_WHEEL,
CLUTTER_SCROLL_SOURCE_FINGER,
CLUTTER_SCROLL_SOURCE_CONTINUOUS
} ClutterScrollSource;
typedef enum
{
CLUTTER_SCROLL_FINISHED_NONE = 0,
CLUTTER_SCROLL_FINISHED_HORIZONTAL = 1 << 0,
CLUTTER_SCROLL_FINISHED_VERTICAL = 1 << 1
} ClutterScrollFinishFlags;
The asserts would only return CLUTTER_SCROLL_SOURCE_UNKNOWN. This
is equal to CLUTTER_SCROLL_FINISHED_NONE which this patch uses
instead. Thus no functional change is intended. This only fixes a
compile warning.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/931
Clutter has a draw debug mode that allows for painting
paint volumes. Right now, this debug mode uses the old
immediate paint mode.
Switch the painting of paint volumes to use paint nodes,
and sneak a few minor style cleanups.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/890
Now that we unconditionally use ClutterActorNode to
paint ClutterActors, move the PAINT private flag to
the ClutterActorNode. This way, we can run the paint
on the actor anywhere inside the paint tree.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/890
When setting the root node as child of a clip or transform node, we add a
new reference to it, without removing the one that we've previously added
when getting it from the actor node (and that won't ever be unset by the
auto-pointer since the root_node is re-associated).
So, once we add the root node as child and re-define it, unref it.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/908
Previously, we would use a single offscreen framebuffer for both
transformations and when a shadow framebuffer should be used, but that
can be dreadfully slow when using software rendering with a discrete GPU
due to bandwidth limitations.
Keep the offscreen framebuffer for transformations only and add another
intermediate shadow framebuffer used as a copy of the onscreen
framebuffer.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/877
A compositor is notably opaque (usually has nothing to be painted on!).
gnome-shell sets this hint, but there's no reason why we wouldn't want
it by default.
Also, the color buffer being cleared messes with stencil clips, as the
clear operation by definition ignores the stencil buffer. We want to
use these more extensively in the future, so just drop this API.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/911
This reverts commit 4918893326.
This commit prevented cogl_stage_cogl_redraw_view() from skipping
swap buffers entirely if the invalidation region ended up empty.
This meant we were actually swapping buffers when we didn't need to.
The source of the glitches was fixed more properly, so this just adds
extra work.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/898
This way, we can simply pop up the Looking Glass and run:
>>> Meta.add_clutter_debug_flags(Clutter.DebugFlag.PICK, 0, 0)
And measure specific actions or events on GNOME Shell.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/862
As we do not prevent the SwapBuffers call from happening, those also
do count. Results in clip area calculations to be right for monitors
that previously did not get invalidated.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/888
Make ClutterActor paint using ClutterTransformNode, ClutterClip
node, and ClutterActorNode. Essencially, the actor node is a
replacement for clutter_actor_continue_paint().
An interesting aspect of this commit is that the order of the
operations is reversed to be preserved.
Before being able to remove the dummy node hack, we'll need to
make ClutterEffects compatible with paint nodes first -- and
naturally, that's enough content for its own merge request.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/872
ClutterActorNode is a paint node that runs the 'paint'
function of an actor. It is a useful helper node to be
used during the transition to paint nodes.
The role of ClutterActorNode will change over time. For
now, it is just a call to clutter_actor_continue_paint(),
which also paints the effects. When ClutterEffect is
ported to paint nodes, ClutterActorNode will morph to
only notify the actor about the painting, and will become
a private node to Clutter.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/872
Previously picking was done on an int (x,y) to address a particular pixel.
While `int` was the minimum precision required, it was also an unnecessary
type conversion.
The callers (input events mainly) all provide float coordinates and the
internal picking calculations also have always used floats. So it was
inconsistent and unnecessary to drop to integer precision in between those.
ABI break: This changes the parameter types for public function
`clutter_stage_get_actor_at_pos`, but its documentation is already
sufficiently vague to not need changing.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/844
This is an extremely straightforward and minimalistic port of
CoglVector APIs to the corresponding Graphene APIs.
Make ClutterPlane use graphene_vec3_t internally too, for the
simplest purpose of keeping the patch focused.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/458
Mutter requires Clutter, which requires Cogl. That means
Clutter requires all Cogl dependencies, and Mutter requires
all Clutter dependencies as well.
However, currently, Clutter does not pull in its dependencies,
which means we need to link against Cogl manually.
Add Clutter dependencies to declare_dependency() so that the
graphene dependency only needs to be declared once, for Cogl,
and pulled together.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/458
This is a deprecated property that is not used anywhere
in the codebase. Not by GNOME Shell. Because it uses the
deprecated ClutterGeometry type, it's a good target for
cleaning up, given that ClutterGeometry will be dropped
later on.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/458
Fog is explicitly deprecated in favour of CoglSnippet API,
and in nowhere we are using this deprecated feature, which
means we can simply drop it without any sort of replacement.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/458
When clutter actors with key focus are destroyed we emit ::key-focus-out on
them just after their destruction. This is against our assumption that no
signal should be emitted after "::destroy" (see GNOME/mutter!769 [1]), and
in fact could cause the shell to do actions that we won't ever stop on
destroy callback.
To avoid this to happen, use a private function to set its key-state (so we
can avoid looking for the stage) and emit ::key-focus-in/out events and use
this value in both clutter_actor_has_key_focus(),
clutter_actor_grab_key_focus() and on unmap and destruction to unset the
stage key focus before we emit the ::destroy signal.
As result of this, we can now avoid to unset the key focus on actor
destruction in the stage.
[1] https://gitlab.gnome.org/GNOME/mutter/merge_requests/769
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1704
Clutter had support for internal children in its early revisions, but they
were deprecated for long time (commit f41061b8df, more than 7 years ago) and
no one is using them in both clutter and in gnome-shell.
So remove any alternative code path that uses internal children.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/816
This is for all intents and purposes the same as
`cogl_object_ref/unref`, but still refers to handles rather than
objects (while we're trying to get rid of the former) so it's a bit of
unnecessary redundant API.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/451
The default value of the ClutterShaderEffect:shader-type
property is CLUTTER_FRAGMENT_SHADER. However, because the
struct field is not actually initialized to it, it ends
up assuming the value 0, which is CLUTTER_VERTEX_SHADER.
Properly initialize ClutterShaderEffect's shader_type to
CLUTTER_FRAGMENT_SHADER.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/846
ClutterActor took a reference in its transition 'stopped' handler,
aiming to keep the transition alive during signal emission even if it
was removed during. This is, however, already taken care of by
ClutterTimeline, by always taking a reference during its 'stopped'
signal emission, so no need to add another one.
This also has the bonus of making reference ownership simpler, as well
as avoidance of double free if an actor was destroyed before a
transition has finished.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/828
Implicit transitions had a referenced taken while emitting the
completion signals, but said reference would only be released if it was
had remove-on-complete set to TRUE.
Change this to instead remove the 'is_implicit' state and mark all
implicit transitions as remove-on-complete. This fixes a
ClutterPropertyTransition leak in gnome-shell triggered by e.g. showing
/ hiding menus.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1740https://gitlab.gnome.org/GNOME/mutter/merge_requests/828
The final version of the function was changed to allow points that are
touching the edge of a quadrilateral to be counted as "inside". Update
the function documentation to refect this.
Also clarify that the function is written in such a way that it is
agnostic to clockwise or anticlockwise vertex ordering.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/783
In `clutter_stage_view_blit_offscreen()`, the given clipping rectangle
is in “view” coordinates whereas we intend to copy the whole actual
framebuffer, meaning that we cannot use the clipping rectangle.
Use the actual framebuffer size, starting at (0, 0) instead.
That fixes the issue with partial repainting with shadow framebuffer
when fractional scaling is enabled.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/820
Clutter actors might emit property changes in dispose, while unparenting.
However we assume that the ::destroy signal is the last one we emit for an
actor, and that starting from this moment the object is not valid anymore,
and so we don't expect any signal emission from it.
To avoid this, freeze the object notifications on an actor during its
disposition, just before the ::destroy signal emission.
Update the actor-destroy test to verify this behavior.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/769
Clutter actors unset their parent on dispose, after emitting the ::destroy
signal, however this could cause ::parent-set signal emission. Since we
assume that after the destruction has been completed the actor isn't valid
anymore, and that during the destroy phase we do all the signal / source
disconnections, this might create unwanted behaviors, as in the signal
callbacks we always assume that the actor isn't in disposed yet.
To avoid this, don't emit ::parent-set signal if the actor is being
destroyed.
Update the actor-destroy test to verify this behavior.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/769
If there is no transformation, use `cogl_blit_framebuffer()` as a
shortcut in `clutter_stage_view_blit_offscreen()`, that dramatically
improves performance when using a shadow framebuffer.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/809
Delayed clutter timelines might be removed while they are still in the
process of being executed, but if they are not playing yet their delay
timeout won't be stopped, causing them to be executed anyway, leading to a
potential crash.
In fact if something else keeps a reference on the timelines (i.e. gjs), the
dispose vfunc delay cancellation won't take effect, causing the timelines to
be started and added to the master clock.
To avoid this, expose clutter_timeline_cancel_delay() function and call it
if a timeline is not playing but has a delay set.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/815https://gitlab.gnome.org/GNOME/mutter/merge_requests/805
If a timeline is delayed and we request to stop or pause it, we are emitting
the "::paused" signal on it, however this has never been started, and so
nothing has really be paused.
So, just try to cancel the delay on pause and return if not playing.
No code in mutter or gnome-shell is affected by this, so it is safe to
change.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/805
Clutter stage used to compute the initial projection using a fixed z
translation which wasn't matching the one we computed in
calculate_z_translation().
This caused to have a wrong initial projection on startup which was then
correctly recomputed only at the first paint.
However, since this calculation doesn't depend on view, but only on viewport
size, perspective's fovy and z_near we can safely do this at startup and
only when any of those parameters change.
Then we can move the computation out _clutter_stage_maybe_setup_viewport()
since the cogl framebuffer viewport sizes aren't affecting this.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1639https://gitlab.gnome.org/GNOME/mutter/merge_requests/803
When suspending, the devices are removed and the virtual device
associated with the corresponding core pointer is disposed.
Add the pointer accessibility virtual device to the core pointer
on resume to restore pointer accessibility on resume if enabled.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/761
Currently, Clutter does picking by drawing with Cogl and reading
the pixel that's beneath the given point. Since Cogl has a journal
that records drawing operations, and has optimizations to read a
single pixel from a list of rectangle, it would be expected that
we would hit this fast path and not flush the journal while picking.
However, that's not the case: dithering, clipping with scissors, etc,
can all flush the journal, issuing commands to the GPU and making
picking slow. On NVidia-based systems, this glReadPixels() call is
extremely costly.
Introduce geometric picking, and avoid using the Cogl journal entirely.
Do this by introducing a stack of actors in ClutterStage. This stack
is cached, but for now, don't use the cache as much as possible.
The picking routines are still tied to painting.
When projecting the actor vertexes, do it manually and take the modelview
matrix of the framebuffer into account as well.
CPU usage on an Intel i7-7700, tested with two different GPUs/drivers:
| | Intel | Nvidia |
| ------: | --------: | -----: |
| Moving the mouse: |
| Before | 10% | 10% |
| After | 6% | 6% |
| Moving a window: |
| Before | 23% | 81% |
| After | 19% | 40% |
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/154,
https://gitlab.gnome.org/GNOME/mutter/issues/691
Helps significantly with: https://gitlab.gnome.org/GNOME/mutter/issues/283,
https://gitlab.gnome.org/GNOME/mutter/issues/590,
https://gitlab.gnome.org/GNOME/mutter/issues/700
v2: Fix code style issues
Simplify quadrilateral checks
Remove the 0.5f hack
Differentiate axis-aligned rectangles
https://gitlab.gnome.org/GNOME/mutter/merge_requests/189
Add a function to check whether a point is inside a quadrilateral
by checking the cross product of vectors with the quadrilateral
points, and the point being checked.
If the passed quadrilateral is zero-sized, no point is ever reported
to be inside it.
This will be used by the next commit when comparing the transformed
actor vertices.
[feaneron: add a commit message and remove unecessary code]
https://gitlab.gnome.org/GNOME/mutter/merge_requests/189
This reverts commit f57ce7254d.
It causes crashes, https://gitlab.gnome.org/GNOME/mutter/issues/735, and
changes various expectations relied upon by the renderer code, and being
close to release, it's safer to revert now and reconsider how to remove
the pending swap counter at a later point.
Add a boolean parameter to the signal to inform the handler whether the
timeout completed successfully or not. This allows the shell to
gracefully end the pie timer animation and show a success animation when
the click happens.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/745
When a dwell click causes the pointer to move to another surface, a
synthetic event is generated which triggers another dwell click.
Make sure we ignore those to avoid dwell clicking twice in a raw.
Suggested-by: Carlos Garnacho <carlosg@gnome.org>
https://gitlab.gnome.org/GNOME/mutter/merge_requests/747
Restarting the dwell click immediately would result in a contant
animation showing.
Start dwell detection in its own timeout handler, which has the nice
effect of not constantly showing a dwell animation and also making sure
that the dwell click timeout is started when pointer movement stops.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/747
Sometimes the dwell timeout doesn't start again after quickly moving the
pointer. That happens if `should_stop_dwell` returns TRUE for the last
motion event we receive: It will stop the current timeout, but not start
a new one until we receive another event where the moved distance is
smaller than the threshold.
To fix this, always call `should_start_dwell` and `start_dwell_timeout`
instead of using an else-block, this makes sure we start a new dwell
timeout still during the same motion event that stopped the old one.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/746
And add the necessary glue so those initialize a X11 clutter backend.
This should get Clutter tests that are dependent on windowing to work
again, thus they were enabled back again.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/672
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
MutterClutterBackendNative, 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
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
Mutter needs to know which framebuffer the paint nodes will be
drawn into, and using cogl_get_draw_framebuffer() directly is
not an option since ClutterRootNode only pushes the draw fb
at draw time.
Expose clutter_paint_node_get_framebuffer().
https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
Incompressible events already pass through unmodified, so queuing them
just wasted time and memory.
We would however like to keep the ordering of events so we can only
apply this optimization if the queue is empty.
This reduces the input latency of incompressible events like touchpad
scrolling or drawing tablets by up to one frame. It also means the same
series of events now arrives at the client more smoothly and not in
bursts.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/711
Until now we would:
1. Enqueue modifier key event on the stage.
2. Update device modifier state.
3. Dequeue and process modifier key event with NEW device modifier state.
But if we consider optimizing out the queuing in some cases then there
will become a problem:
1. Process modifier key event with OLD device modifier state.
2. Update device modifier state.
To correct the above we now do:
1. Update device modifier state.
2. Queue/process modifier key event with NEW device modifier state.
It appears commit dd940a71 which introduced the old behaviour was correct
in the need to update the device modifier state, but is at least no longer
correct (if it ever was) that it should be done after queuing the event.
If queuing is working, as it is right now, then it makes no difference
whether the device modifier state is updated before or after. Because both
cases will come before the dequeing and processing.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/711
Thanks to the now removed global/context grabs, we can move pointer and
keyboard grabs back home to where they belong.
While at it, also add handling of CLUTTER_TABLET_DEVICE devices to
`on_grab_actor_destroy` and `clutter_input_device_get_grabbed_actor`.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/536
If possible, GLib will try to use the va_marshaller to pass the signal
arguments, rather than unboxing into and out of a `GValue`. This is much
more performant and especially good for often-thrown signals.
The original bug even mentions Clutter performance issues as a drive to
implement the va_marshaller in GLib (see
https://bugzilla.gnome.org/show_bug.cgi?id=661140).
https://gitlab.gnome.org/GNOME/mutter/merge_requests/700
Some of the marshallers we generate in `clutter-marshal.list` are also
available in GLib, so we don't need to generate them ourselves. Even
more, by passing NULL to `g_signal_new` in these cases will actually
internally optimize this even more by also setting the valist
marshaller, which is a little bit faster than the regular marshalling
using `GValue` and libffi.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/700
`g_object_notify()` actually takes a global lock to look up the property
by its name, which means there is a performance hit (albeit tiny) every
time this function is called. For this reason, always try to use
`g_object_notify_by_pspec()` instead.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/703
Since commit 0eab73dc, actors are only allocated when they are actually
visible. While this generally works well, it breaks - because of *course*
it does - ClutterClones when the clone source (or any of its ancestors)
is hidden.
Force an allocation in that case to allow the clone's paint to work as
intended.
https://gitlab.gnome.org/GNOME/mutter/issues/683
The type has been deprecated, so stop using it. The easiest replacement
would be to add our own struct, but considering that separate name/value
arrays are easier to free (g_auto!) and we already do the split in one
place, go that route.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/689
Glib stopped providing any fallback implementations on systems without
memmove() all the way back in 2013. Since then, the symbol is a simple
macro around memmove(); use that function directly now that glib added
a deprecation warning.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/689
Currently nothing in the clutter machinery prevents hidden portions
of the actor tree from calling queue_relayout() (and having it fully
honored).
But that allocation should not be necessary till the actor is shown,
and one of the things we do on show() is queueing a relayout/redraw
after flagging the actor as visible.
We can simply defer clutter_actor_allocate() calls till that show()
call, and leave the needs_allocate and other flags set so we ensure
the allocation is properly set then.
This should cut down some needless operations when invisible portions
of the actor tree change indirectly due to user interaction, or due
to background activity.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/677
Clutter has two motion event toggles: one in the global context, and
one per stage. The global one is deprecated, and currently unused.
Remove the global motion event handling.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/666
The “togglekeys” setting is to emit a sounds whenever the state of one
of the modifiers keys (CAPS lock, NUM Lock, SCROLL lock) is changed, it
has nothing to do with the rest of the accessibility settings.
Therefore, there is no need to reset the various timers used by
accessibility whenever the “togglekeys” setting is changed.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/614
ClutterStage:after-paint now does not guarantee a valid
implicit framebuffer pushed to the stack. Instead, use
the new 'paint-view' signal, that is emitted at a point
in the drawing routine where a framebuffer is pushed.
In addition to that, stop using the implicit framebuffer
API and port the actor-shader-effect test to read from
the view's framebuffer directly.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/623
Now that ClutterStageView is embraced as part of the public
set of Clutter classes, is it possible to give consumers
of this API more information and control over the drawing
routines of ClutterStage.
Introduce ClutterStage:paint-view, a signal that is emitted
for painting a specific view. It's defined as a RUN_LAST
signal to give anyone connecting to it the ability to run
before the view is actually painted, or after (using the
G_CONNECT_AFTER flag, or g_signal_connect_after).
This signal has a corresponding class handler, which allows
Mutter to have much finer control over the painting routines.
In fact, this will allow us to implement a "paint phase watcher"
mechanism in the following patches.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/623
ClutterStage:after-paint is supposed to be emitted after all
painting is done, but before the frame is finished. However,
as it is right now, it is being emitted after each view is
painted -- on multi-monitor setups, after-frame is being
emitted multiple times.
Send after-paint only once, after all views are painted and
before finishing the frame.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/623
As a compositor toolkit, it makes sense to allow consumers
of Clutter interact with the stage views themselves. As such,
ClutterStageView should be a public class.
As such, it is now included in clutter.h and should not be
included directly.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/623
When libwacom is configured disabled, this error appears:
../clutter/clutter/x11/clutter-input-device-xi2.c: In function ‘clutter_input_device_xi2_finalize’:
../clutter/clutter/x11/clutter-input-device-xi2.c:122:7: error: ‘device_xi2’ undeclared (first use in this function)
if (device_xi2->inhibit_pointer_query_timer)
Fix it with the "obvious" solution.
This code was added in c1303bd642.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/611
When a user moves their cursor the perceived behaviour is that it will
pick what is under the cursor. However this isn't how picking works.
Picking does a virtual redraw of the screen, so in some cases what gets
picked isn't the same as what the user could see on the previous frame.
It more represents what will be drawn on the next frame than what is on
screen at present.
It may be unsafe to change these semantics, and they are useful anyway.
Just document it better.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/214
After 4faeb12731, the maximum time allowed for an update to happen
is calculated as:
max_render_time_allowed = refresh_interval - 1000 * sync_delay;
However, extremely small refresh intervals -- that come as consequence
to extremely high refresh rates -- may fall into an odd numerical range
when refresh_interval < 1000 * sync_delay. That would give us a negative
time.
To be extra cautious about it, add another sanity check for this case.
Change suggested by Jasper St. Pierre.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/363
The presentation timing logic (via `master_clock_get_swap_wait_time`) now
works unconditionally. By "works" we mean that a result of zero from
`master_clock_get_swap_wait_time` actually means zero now. Previously
zero could mean either a successful result of zero milliseconds or that
the backend couldn't get an answer. And a non-zero result is the same as
before.
This works even if the screen is "idle" and even if the backend doesn't
provide presentation timestamps. So now our two fallback throttling
mechanisms of relying on `CLUTTER_FEATURE_SWAP_THROTTLE` and decimating
to `clutter_get_default_frame_rate` can be deleted.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/406 and
https://bugzilla.gnome.org/show_bug.cgi?id=781835https://gitlab.gnome.org/GNOME/mutter/merge_requests/363
If `last_presentation_time` is zero (unsupported) or just very old
(system was idle) then we would like to avoid that triggering a large
number of loop interations. This will get us closer to the right answer
without iterating.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/363
That could happen if the backend did not provide presentation timestamps,
or if the screen was not changing other than the hardware cursor:
if (stage_cogl->last_presentation_time == 0||
stage_cogl->last_presentation_time < now - 150000)
{
stage_cogl->update_time = now;
return;
}
By setting `update_time` to `now`, master_clock_get_swap_wait_time()
returns 0:
gint64 now = g_source_get_time (master_clock->source);
if (min_update_time < now)
{
return 0;
}
else
{
gint64 delay_us = min_update_time - now;
return (delay_us + 999) / 1000;
}
However, zero is a value unsupported by the default master clock
due to:
if (swap_delay != 0)
return swap_delay;
All cases are now handled by extrapolating when the next presentation
time would be and calculating an appropriate update time to meet that.
We also need to add a check for `update_time == last_update_time`, which
is a situation that just became possible since we support old (or zero)
values of `last_presentation_time`. This avoids getting more than one
stage update per frame interval when input events arrive without
triggering a stage redraw (e.g. moving the hardware cursor).
https://gitlab.gnome.org/GNOME/mutter/merge_requests/363
Instead of crazy refresh rates >1MHz falling back to 60Hz, just honour
them by rendering unthrottled (same as `sync_delay < 0`). Although I
wouldn't actually expect that path to ever be needed in reality, it just
ensures an infinite `while` loop never happens.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/363
When using evdev (for Wayland), the backend receives all device events
and queue them for clutter.
Hook up the pointer accessibility handlers in clutter's main processing
queue, so that we get better accuracy for pointer location.
We need to avoid doing this on X11 though because X11 relies on the raw
events for this to work reliably, so the same is already done in the
X11 backend when using X11.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/512
Pointer accessibility features requires to receive all pointer events
regardless of X11 grabs.
Add XI2 raw events mask and hook up the pointer accessibility handlers
to the raw motion and button press/release events.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/512
Add support for click assist, namely simulated secondary click (on a
long primary button press) and hover click support (simulate a click when
the pointer remains static for some time).
https://gitlab.gnome.org/GNOME/mutter/merge_requests/512
Add the required signaling in place in clutter device manager to notify
the upper layers (namely, the shell) whenever a click assist delay or
gesture is started or stopped.
This will allow the shell to implement a visual feedback for click
assist operations.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/512
For accessibility features, being either keyboard accessibility to
implement mousekeys, or pointer accessibility to implement simulated
secondary click or dwell click, we need to have a virtual device.
Add that virtual device in ClutterInputDevice so it can be used either
for keyboard or pointer accessibility.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/512
Certain arguments like `-fno-omit-frame-pointer` break GIR creation.
Lets handle this like we do for the rest of mutter and duplicate the
relevant arguments from `clutter_c_args`.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/601
Spotted while adding tracing to swap buffers, we only enter
the first part of the if condition when use_clipped_redraw
is TRUE, so it's pretty safe to assume it's TRUE.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/197
The idea here is to be able to visualize and immediately
understand what is happening. Something like:
```
[ view1 ] [ view2 ]
[---- Layout ---][------ Paint ------][ Pick ]
[================== Update =====================]
```
But with colors. A few of the previous profiling data
sections were removed, since they didn't really add to
reading the graph.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/197
Add debug flags based on meson's `debug` option instead of `buildtype`.
This allows custom build configurations to behave like a debug or release build.
Add `-fno-omit-frame-pointer` to Mutter/Cogl. Not to Clutter though, as that would
require more changes to how Clutter's gir is created
Remove `-DG_DISABLE_CAST_CHECKS` from Clutter in debug builds
Add `-DG_DISABLE_CHECKS`, `-DG_DISABLE_ASSERT` and `-DG_DISABLE_CAST_CHECKS` to all
non-debug builds but `plain`, which explicitly should not have any compile flags
Use `cc.get_supported_arguments`, so it becomes more obvious to the user which flags
are set during compilation
https://gitlab.gnome.org/GNOME/mutter/merge_requests/497
Commit df7d8e2cb highlights a crash on test_destroy_destroy, in fact it could
happen that calling clutter_actor_destroy on a child while iterating on the
list, would implicitly call test_destroy_remove that tries to modify the list
at the same time. Causing a memory error.
So instead of manually free the children list, just ensure that this list is
valid and that when the object destruction is done, this is free'd.
See: https://gitlab.gnome.org/GNOME/mutter/merge_requests/576https://gitlab.gnome.org/GNOME/mutter/merge_requests/581
Commit cabcad185 removed the call to cogl_set_source_color4ub() before
cogl_fill_path(), so instead of the previously assigned selection color,
the background is drawn with the last set source.
In order to honour the newly added framebuffer parameter and still apply
the correct color, switch from cogl_fill_path() to the (deprecated!)
cogl_framebuffer_fill_path() method.
https://gitlab.gnome.org/GNOME/mutter/issues/494
If an update (new frame) had been scheduled already before
`_clutter_stage_cogl_presented` was called then that means it was
scheduled for the wrong time. Because the `last_presentation_time` has
changed since then. And using an `update_time` based on an outdated
presentation time results in scheduling frames too early, filling the
buffer queue (triple buffering or worse) and high visual latency.
So if we do receive a presentation event when an update is already
scheduled, remember to reschedule the update based on the newer
`last_presentation_time`. This way we avoid overfilling the buffer queue
and limit ourselves to double buffering for less visible lag.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/334
Prerequisite: https://gitlab.gnome.org/GNOME/mutter/merge_requests/520https://gitlab.gnome.org/GNOME/mutter/merge_requests/281
Pango functions pango_unichar_direction() and pango_find_base_dir() have been
deprecated in pango 1.44, since these are used mostly clutter and gtk, copy the
code from pango and use fribidi dependency explicitly.
This is the same strategy used by Gtk.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/583
The `last_presentation_time` is usually a little in the past (although
sometimes in the future depending on the driver). When it's over 2ms
(`sync_delay`) in the past that would trigger the while loop to count up so
that the next `update_time` is in the future.
The problem with that is for common values of `last_presentation_time`
which are only a few milliseconds ago, incrementing `update_time` by
`refresh_interval` also means counting past the next physical frame that
we haven't rendered yet. And so mutter would skip that frame.
**Example**
Given:
```
last_presentation_time = now - 3ms
sync_delay = 2ms
refresh_interval = 16ms
next_presentation_time = last_presentation_time + refresh_interval
= now + 13ms
-3ms now +13ms +29ms +45ms
----|--+------------|---------------|---------------|----
: :
last_presentation_time next_presentation_time
```
Old algorithm:
```
update_time = last_presentation_time + sync_delay
= now - 1ms
while (update_time < now)
(now - 1ms < now)
update_time = now - 1ms + 16ms
update_time = now + 15ms
next_presentation_time = now + 13ms
available_render_time = next_presentation_time - max(now, update_time)
= (now + 13ms) - (now + 15ms)
= -2ms so the next frame will be skipped.
-3ms now +13ms +29ms +45ms
----|--+------------|-+-------------|---------------|----
: : :
: : update_time (too late)
: :
last_presentation_time next_presentation_time (a missed frame)
```
New algorithm:
```
min_render_time_allowed = refresh_interval / 2
= 8ms
max_render_time_allowed = refresh_interval - sync_delay
= 14ms
target_presentation_time = last_presentation_time + refresh_interval
= now - 3ms + 16ms
= now + 13ms
while (target_presentation_time - min_render_time_allowed < now)
(now + 13ms - 8ms < now)
(5ms < 0ms)
# loop is never entered
update_time = target_presentation_time - max_render_time_allowed
= now + 13ms - 14ms
= now - 1ms
next_presentation_time = now + 13ms
available_render_time = next_presentation_time - max(now, update_time)
= (now + 13ms) - now
= 13ms which is plenty of render time.
-3ms now +13ms +29ms +45ms
----|-++------------|---------------|---------------|----
: : :
: update_time :
: :
last_presentation_time next_presentation_time
```
The reason nobody noticed these missed frames very often was because
mutter has some accidental workarounds built-in:
* Prior to 3.32, the offending code was only reachable in Xorg sessions.
It was never reached in Wayland sessions because it hadn't been
implemented yet (till e9e4b2b72).
* Even though Wayland support is now implemented the native backend
provides a `last_presentation_time` much faster than Xorg sessions
(being in the same process) and so is less likely to spuriously enter
the while loop to miss a frame.
* For Xorg sessions we are accidentally triple buffering (#334). This
is a good way to avoid the missed frames, but is also an accident.
* `sync_delay` is presently just high enough (2ms by coincidence is very
close to common values of `now - last_presentation_time`) to push the
`update_time` into the future in some cases, which avoids entering the
while loop. This is why the same missed frames problem was also noticed
when experimenting with `sync_delay = 0`.
v2: adjust variable names and code style.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=789186
and most of https://gitlab.gnome.org/GNOME/mutter/issues/571https://gitlab.gnome.org/GNOME/mutter/merge_requests/520
We only call _clutter_input_device_update with devices that are not
Keyboard devices. Also passing a Keyboard device to a function whose
primary purpose is picking should be considered a bug in the caller.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/547
We're bailing out of clutter_stage_cogl_add_redraw_clip() early without
doing anything if we're ignoring redraw clips, so no need to call it if
we already know that will be the case.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/547
GList's used in legacy code were free'd using a g_slist_foreach + g_slist_free,
while we can just use g_slist_free_full as per GLib 2.28.
So replace code where we were using this legacy codepath.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/576
GList's used in legacy code were free'd using a g_list_foreach + g_list_free,
while we can just use g_list_free_full as per GLib 2.28.
So replace code where we were using this legacy codepath.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/576
Moving an actor with a ClutterDeformEffect applied flickers because
the depth_testing, setting the depth testing test function to
COGL_DEPTH_TEST_FUNCTION_LEQUAL fixes the problem.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/507
When the pointer is grabbed, we send the crossing events that are
initiated by this pointer only to the actor that has the grab. For
grabbed touch sequences, we always capture and bubble the crossing
events right now.
Fix this and make grabbed pointers and touch sequences behave the same
by sending touch crossing events only to the grab actor.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/422
It's important to cancel click actions when we get a touch cancel event,
otherwise the long press event might get emitted after the compositor
took over the touches because it detected a gesture.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/396
Clutter does the nicety of connecting just created PangoContexts to
ClutterBackend signals in order to update it on resolution/font changes.
However the way the signals are disconnected (automatically via
g_signal_connect_object() auto-disconnect feature) may incur into
performance issues with a high enough number of ClutterActors with a
PangoContext (eg. ClutterText) as the lookup by closure is linear across
all signals and handlers.
Keep the handler IDs around, and disconnect them specifically on dispose
so it is more O(1)-ish.
Related: https://gitlab.gnome.org/GNOME/mutter/issues/556
The clutter/evdev implementation of mousekeys is designed after the
current implementation in X11, and works when the setting is enabled
regardless of the status of NumLock.
The GNOME documentation on accessibility features states however that
mousekeys work only when NumLock is OFF:
https://help.gnome.org/users/gnome-help/stable/mouse-mousekeys.html
Change the clutter/evdev implementation to match the documentation, i.e.
disable mousekeys when NumLock in ON so that switching NumLock ON
restores the numeric keypad behaviour.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/530
The keyboard accessibility setting "enable" is actually even more
misleading that initially anticipated, as it does not control the
entire keyboard accessibility feature, but just the "enable by
keyboard" feature, i.e. being able to enable or disable stickykeys
or slowkeys using various keyboard actions.
Yet the accessibility features should still work even if the "enable"
setting is unset, those can be controlled by the accessibility menu in
GNOME Shell for example.
Change the clutter/evdev implementation to match that behavior as found
in the x11 backend, so both backends are now consistent.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/531
In a multi-monitor setup there is a separate paint run for each monitor.
If an actor doesn't intersect the first monitor painted then it is culled
out for that monitor to save time. Unfortunately this would mean
`clutter_actor_paint` was setting `is_dirty = FALSE` before the actor had
yet been painted on any monitor.
This meant that effects like `ClutterOffscreenEffect` were not receiving
the flag `CLUTTER_EFFECT_PAINT_ACTOR_DIRTY` when they should have, and
so would rightfully think they don't need to do a full internal
invalidation. So `ClutterOffscreenEffect`, and probably other effects,
did not repaint correctly unless on the first monitor in the list.
The fix is to simply avoid setting `is_dirty = FALSE` on those paint
runs where the actor has been culled out (`clutter_actor_continue_paint`
wasn't called). It is only safe to clear the flag after
`clutter_actor_continue_paint` has been called at least once per stage
paint.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1049https://gitlab.gnome.org/GNOME/mutter/merge_requests/511
clutter_input_device_get_physical_size was just used for device mapping
heuristics in MetaInputMapper. It now started using the info from udev
on for both backends, so this means this clutter API is no longer
necessary.
https://gitlab.gnome.org/GNOME/mutter/issues/514
Enabling keyboard accessibility features on Wayland from the keyboard
was wrongly assumed to be controlled by the "togglekeys" setting,
whereas it should be simply controlled by the "enable" setting.
As "togglekeys" is off by default and doesn't have a UI option to
enable, that would prevent turning on or off the keyboard accessibility
features using the keyboard.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/501
Meson 0.50.0 made passing an absolute path to install_headers()'
subdir keyword a fatal error. This means we have to track both
relative (to includedir) paths for header subdirs and absolute
paths for generated headers now :-(
https://gitlab.gnome.org/GNOME/mutter/merge_requests/492
The ClutterVirtualInputDevice API was fixed to use Clutter button
internal codes, whereas the mousekeys still uses evdev codes.
Change the mousekeys implementation to use the Clutter button code
instead to remain compatible with the ClutterVirtualInputDevice API.
Fixes: 24aef44b (Translate from button internal codes to evdev)
https://gitlab.gnome.org/GNOME/mutter/merge_requests/473
Since e3e933c4 a keyval can be temporarily remapped to an unused keycode. Due to
some limitations in XTestFakeKeyEvent, the remapping has to be done in the first
xkb group/layout. In case there are two or more keyboard layouts enabled and the
selected keyboard layout is not the first, clutter_keymap_x11_keycode_for_keyval
will fail to retrieve the correct keycode for a remapped keyval. Let's use the
reserved_keycodes map in order to retrieve the correct keycode if needed.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/443
The clamped rectangle currently could not fully contain the original fractional
rectangle because it doesn't take care of the fact that the new width should
consider the fact that flooring we'd translate the rectangle, and thus to cover
the same area we need to take care of it.
So, to properly compute the width and height, calculate x2 and y2 first and then
use this ceiled value to compute the actual width using the floored x1 and y1.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/3
When we try to update the FB, we might face the case in which the effect target
framebuffer does not need any redraw, because it's already properly sized and
scaled, but the filter applied to the pipeline is not, because it has been
computed for a non-fractional scaling.
This is happens for example to clutter actors with a flattening effect (i.e.
override redirect mode set), that might have been generated properly for a
celied scaling level, but when we go fractional we need to ensure to use a
linear filter, as the 1:1 texel:pixel assumption is not true anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=765011https://gitlab.gnome.org/GNOME/mutter/merge_requests/3
At this level we use ceiled resource-scale when painting fractional value
When using fractional scaling we still need to create an integer-sized
texture and then we should paint it using a size which is proportional
to the real actor size ratio, and only paint a subsample of it, but this
doesn't seem to work properly with some weird scaling values.
Then, it's just better to draw the texture ceiled and then we scale it
down to match the proper actor scaling at paint level.
https://bugzilla.gnome.org/show_bug.cgi?id=765011https://gitlab.gnome.org/GNOME/mutter/merge_requests/3
When resource scale is set we need to generate a scaled PangoLayout (by adding
a new scale attribute, or adjusting the one we already have according the
resource scale), then it has to be painted with proper scaling matrix.
So everything that has to do with PangoLayout has to be in real coordinates,
then clutter logical coords multiplied by resource scaling.
While the actual size of the layout is the one of the PangoLayout divided by
resource scale.
We map the text positions to logical coords by default, while using
the pixel coordinates when painting.
We fall back to scale 1 when calculating preferred size if no scale is
known. The pango layout will not have set a layout scale attribute,
meaning it'll be 1, thus we should just assume the layout scale is 1 here.
Not doing so might result in the preferred size being 0x0 meaning the
actor won't be laid out properly.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/135https://bugzilla.gnome.org/show_bug.cgi?id=765011https://gitlab.gnome.org/GNOME/mutter/merge_requests/3
A clutter actor might be painted on a stage view with a view scale
other than 1. In this case, to show the content in full resolution, the
actor must use a higher resolution resource (e.g. texture), which will
be down scaled to the stage coordinate space, then scaled up again to
the stage view framebuffer scale.
Use a 'resource-scale' property to save information and notify when it
changes.
The resource scale is the ceiled value of the highest stage view scale a
actor is visible on. The value is ceiled because using a higher
resolution resource consistently results in better output quality. One
reason for this is that rendering is often not perfectly pixel aligned,
meaning even if we load a resource with a suitable size, due to us still
scaling ever so slightly, the quality is affected. Using a higher
resolution resource avoids this problem.
For situations inside clutter where the actual maximum view scale is
needed, a function _clutter_actor_get_real_resource_scale() is provided,
which returns the non-ceiled value.
Make sure we ignore resource scale computation requests during size
requests or allocation while ensure we've proper resource-scale on
pre-paint.
https://bugzilla.gnome.org/show_bug.cgi?id=765011https://gitlab.gnome.org/GNOME/mutter/merge_requests/3
