The helper doesn't do anything that makes it worth
to be exposed as public API. End-users, such as GNOME Shell could have
an in-tree helper if they end up using it that much.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3086>
For frame updates in response to sporadic user interaction, this results
in input → output latency somewhere between the minimum possible and the
minimum plus the length of one display refresh cycle (assuming the frame
update can complete within a refresh cycle).
Applying a max_render_time based deadline which corresponds to higher
than the minimum possible latency would result in higher effective
minimum latency for sporadic user interaction.
This was discovered by Ivan Molodetskikh, based on measurements
described in https://mastodon.online/@YaLTeR/110848066454900941 .
v2:
* Set min_render_time_allowed_us = 0 as well, to avoid unthrottled
frame events. (Robert Mader)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3174>
When more than one refresh interval has passed since
last_presentation_time_us.
I honestly can't tell if the previous calculation was correct or not,
but I'm confident the new one is, and it's simpler.
v2:
* ASCII art diagram didn't make sense anymore, try to improve
(Ivan Molodetskikh)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3330>
The absolute modelview contains OpenGL coordinates, which have a higher
chance to not be invertible or, when doing so, introduce rounding
errors. These again often result in relative transforms becoming 3D
instead of 2D, making us miss optimized code paths down the line.
Thus cache stage-relative matrices instead, improving correctness and
possibly performance.
While on it also add some fast paths for cases where we can skip
calculating inverted matrices altogether and change variable names to be
more precise.
Fixes: dfd58ca8f1 ("clutter/actor: Extend caching in apply_relative_transformation_matrix")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3286>
When CLUTTER_ENABLE_DEBUG is not defined, then CLUTTER_NOTE is defined
as an empty block of code. As a result of that, jitter_us is in that
situation unused, and a compiler warning about this unused variable
appears.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3275>
Apart from a few edge cases we can avoid walking the tree and transform
to the ancestor coordinate space by multiplying the actor stage-relative
matrix with the inverse of the ancestor's stage-relative matrix.
Since the stage-relative matrices are cached, this reduces the number of
matrix multiplications we do in many situations considerably.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3259>
This used to be the HW device that triggered the crossing (i.e.
the mouse moving the pointer, etc), or the logical device if the
crossing event happened through other means than input device
events, e.g. relayouts.
The move to ClutterEvent constructors went a bit too far in
the simplifications and broke these expectations for input-generated
crossing events.
Make this event constructor behave like the other events: receive
a source device, and figure out the corresponding logical device from
there. Also pass the source device as it'd be expected, in the
input-induced crossing event generation paths.
Fixes: a8c62251f8 ("clutter: Port stage crossing events to new constructors")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2981
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3256>
The stage has the knowledge about input that is ongoing over it
(incl. things like styli and touchpoints). Add an iterator API
for these devices/touchpoints, so they can be used for calculations
and heuristics in other places of the code.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3059>
So far, we expected all events to have input devices set on them, IM events
lost theirs with commit 6aa42d6dad. This somewhat made sense, because IM
events are not backed by any actual device, they are generated by us in
response to eg. an OSK key press.
To fullfil the assumption that all devices at least have a logical input
device set, pass the seat to the clutter_event_im_new() constructor and then
set the device to the logical keyboard device. The source_device we leave
empty, since there is no actual physical device that this event came from.
Fixes: 6aa42d6dad
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3236>
The assertion for !implicit_grab_cancelled in the
`grab_actor == old_grab_actor` case of
clutter_stage_notify_grab_on_pointer_entry() is meant to do a simple
sanity-check to ensure the grab machinery is working as intended: During a
seat grab, all input gets delivered to the tree inside the grab, and all
implicit grabs outside of that tree are cancelled.
When a new seat grab on the same actor as the existing one happens, we run
through the cancellation machinery for implicit grabs anyway, so we might as
well check that the assumption mentioned above holds true: By asserting that
no implicit grabs were cancelled, we know that no implicit grabs exist
outside of the existing seat grab tree.
This assertion is slightly over-eager though due to the way we set
implicit_grab_cancelled: We initialize it to TRUE in the
entry->press_count > 0 case and then only set it to FALSE once we find an
implicit grab that may remain active. If there are no implicit grabs though
(while entry->press_count is still >0), we never set implicit_grab_cancelled
to FALSE, triggering the assertion in question even though no implicit grabs
got cancelled.
There's two possible solutions for this: Either dropping the assertion, or
refactoring it so it observes the situation where the implicit grabs were
already undone. This commit implements the latter.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2700
Fixes: debbd88f8c ("clutter/stage: Cancel parts of implicit grabs when ClutterGrabs happen")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3216>
Dropped obsolete Free Software Foundation address pointing
to the FSF website instead as suggested by
https://www.gnu.org/licenses/gpl-howto.html
keeping intact the important part of the historical notice
as requested by the license.
Resolving rpmlint reported issue E: incorrect-fsf-address.
Signed-off-by: Sandro Bonazzola <sbonazzo@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3155>
This is at best pointless, since the relayout will change pointer
picking conditions, and buggy at worst, since the actor being
relayout is not at an state that it can be asked during picking.
This specifically fixes warnings like:
Can't update stage views actor <unnamed>[<Gjs_ui_workspacesView_WorkspacesDisplay>:0x5601dd557050] is on because it needs an allocation.
Can't update stage views actor <unnamed>[<Gjs_ui_workspacesView_WorkspacesView>:0x5601edcf6aa0] is on because it needs an allocation.
Can't update stage views actor <unnamed>[<Gjs_ui_workspace_Workspace>:0x5601ee163dc0] is on because it needs an allocation.
Can't update stage views actor <unnamed>[<Gjs_ui_workspace_WorkspaceBackground>:0x5601ee1c85b0] is on because it needs an allocation.
Can't update stage views actor <unnamed>[<ClutterActor>:0x5601ee4db280] is on because it needs an allocation.
Can't update stage views actor <unnamed>[<Gjs_ui_windowPreview_WindowPreview>:0x5601ee1840c0] is on because it needs an allocation.
Can't update stage views actor <unnamed>[<Gjs_ui_workspace_Workspace>:0x5601ebe1d1b0] is on because it needs an allocation.
Can't update stage views actor <unnamed>[<Gjs_ui_workspace_WorkspaceBackground>:0x5601edbd3420] is on because it needs an allocation.
Can't update stage views actor <unnamed>[<ClutterActor>:0x5601ee3cd630] is on because it needs an allocation.
Can't update stage views actor <unnamed>[<StLabel>:0x5601ee685730] is on because it needs an allocation.
Can't update stage views actor <unnamed>[<ClutterText>:0x5601ed5b5f20] is on because it needs an allocation.
When trying to dismiss the overview with a 3fg touchpad gesture
while the pointer is over a window clone.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6935
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3220>
This are called when a clone directly attaches to an actor. While not
reliable to know whether a particular actor is cloned or not, one can at
least this way get notified about whether an actor in particular is
cloned.
This can be useful for e.g. the MetaWindowActor, as it's what's most
likely cloned, e.g. for alt-tab views etc.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3019>
Adds va_marshallers to the ClutterStage signals. This allows for better
stack traces to be retrieved when profiling. Additionally, since the
generic marshaller was using GBoxedCopy/GBoxedFree functions for the
GValue usage, the previous code was acquiring a global reader/writer
lock in GObject via g_boxed_free() usage.
With G_SIGNAL_TYPE_STATIC_SCOPE, the generated marshallers can avoid
the additional copy/free on the instance.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3204>
Same reasoning holds than with touchpad gesture events in the
previous commit, this will be the first event seen from a specific
device and will require early handling, or crashes may follow.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3198>
With commit be3bca01a7 in place, we now possibly skip early calls
to clutter_stage_repick_device() happening early during initialization.
These were also indirectly the ones that eventually ended up in
the first call to clutter_stage_pick_and_update_device() actually
initializing the PointerDeviceEntry.
With this no longer happening, we may end up with no PointerDeviceEntry
implicitly set up after initialization, which may fail if the first
event received from the seat pointer does not in fact trigger the
clutter_stage_pick_and_update_device() call necessary to make things
work from there on.
And this does indeed happen on touchpads, since the first input event
obtained after CLUTTER_DEVICE_ADDED is CLUTTER_TOUCHPAD_* instead
of CLUTTER_MOTION. This finds an unset PointerDeviceEntry and crashes
since the pointer device does still have no "presence" on the stage.
Fix this by making CLUTTER_TOUCHPAD_* events also trigger a
device update, so the fist event handled does always trigger the
necessary device update.
Fixes: be3bca01a7 ("clutter: Check that pointer has coordinates prior to repick")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2978
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3198>
This data is commonplace enough that it makes sense to keep it
as generic event data. Make these fields take a hard refcount, like
the private data used to do, and drop these fields from the
ClutterEventPrivate struct.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3190>
In future commits, we will want to create DMA-BUFs with pixel
formats other than COGL_PIXEL_FORMAT_BGRX_8888. In preparation
for that, let's start passing a new pixel format parameter to
this function, and the corresponding winsys vfunc.
All callers of this function pass COGL_PIXEL_FORMAT_BGRX_8888
for now. Next commits will change that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3175>
The device/sequence may not currently have a set of coordinates to return.
We correctly leave the out values uninitialized, but don't tell the upper
layers in any way.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3183>
We have a mechanism to trigger repick after animations on
clutter_actor_set_final_state(), but this will not happen if
animations are disabled.
In this case, shell transitions and other typically animatable
changes on the transform of actors will not naturally trigger
a pointer repick when those get instantly changed to the final
state, possibly preserving the cached state and missing the
just popped in actor altogether.
Trigger an instant repick on animation-less transform changes,
so that these situations are also handled correctly, and the
pointer drops the cached state and is able to find the new
actor.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2918
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3168>
The clutter_seat_handle_event_post() function wants to handle
CLUTTER_DEVICE_ADDED/REMOVED to perform signal emission, but
checks (and asserts) that every event going through it has a
source device.
This is no longer quite true for IM events (they are attached
to the ClutterSeat's keyboard, not a HW device), so the assert
can now fire off (of course undesiredly).
But anyways, for events built through
clutter_event_device_notification_new() (the ones this function
is interested in, after all), it is already a precondition check
that the device is proper at the time of creating the event, so
asserting for it here is redundant.
We can drop this overly generic assert, this is already ensured
for the events that matter, anyways.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3167>
