This aims to provide the color state used for compositing for a specific
view. It's currently hard coded to default, but will eventually be
configured depending on the monitor and configuration. It's intended to
be used as a target color state for rendering with color awareness.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3433>
The cogl shader cache uses snippet pointers as cache keys, meaning even
if we generate two identical snippets; if they have different pointer
addresses, they'll generate separate cache entries. Handle this by
caching our snippets on the context.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3433>
This helper generates shader snippets that converts pixels from one
color state to another. For example if there is content with sRGB color
state that should be converted to linear BT.2020 before being written to
the framebuffer, a shader that makes the pixel go through the following
steps will be generated:
1. sRGB EOTF
2. Luminance gain (hard coded for now)
3. Color space mapping
The intention is that it should be possible to composite in a linear
color space, into an intermediate framebuffer, which is then passed
through an inverse EOTF to produce linear content in the output color
state.
When transforming from BT.2020/PQ to sRGB/sRGB, clamping to the sRGB
max luminance is done.
Cases where direct transform is also handled, i.e. where one doesn't go
via an linear intermediate buffer, in which case there might be both an
EOTF and an inverted EOTF in the same shader snippet to still do color
space mapping using optical color encoding. This will be used for e.g.
transforming cursor sprites.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3433>
An unknown color space isn't very useful to have, as there is not very
actionable what to do with it. Rename it to 'default'. Later it'll be
used to an implicit color space, which in practice will be treated as
sRGB.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3433>
The context can be set via a property (currently unused) or via the
current global singleton as a fallback. It means API that acts on an
actor can avoid going via any globals.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3433>
This gives greater control to the callers on the place where a grab is being
activated, this may make a difference in the handling of crossing events
triggered through it, e.g. by having callers rely on having already obtained
a ClutterGrab prior to handling the resulting effects.
The "input only" grab has also been turned inactive by default, in order to
to have the ClutterGrab pointer available for checks at the MetaWaylandEventHandler
focus changing methods triggered through grab activation.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3463
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3747>
Inside the "if (clutter_actor_has_accessible (actor))" condition,
the 'atk_child' variable is set and a signal is emitted on it.
There is a classic ref/unref dance around the signal to guarantee
that 'atk_child' won't be destroyed.
However, this ref/unref dance doesn't work, because the unref is
done *before* the 'atk_child' variable is used again. So if this
was the last reference to it, it would have been destroyed in the
unref call, then used for another signal emission a few lines down.
That's a use-after-free.
Fix that by declaring the 'atk_child' variable with g_autoptr. This
delays the unref until the very end of the function, and is NULL safe.
Also add a sneaky assertion, just for extra safety.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3828>
Currently AtkActor iface is implemented by CallyActor as well
as a ton of infrastructure just for one action in ClutterText, the
activate action.
Instead, simplify the whole thing and move the AtkAction implementation
where it supposed to be.
This refactoring would help with merging Cally within Clutter in
the future
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3814>
If the presentation time isn't known, e.g. if the monitor is virtual and
the actual presentation happens far away, the presentation time we
actually received tends to be the time a frame was presented to the next
layer, meaning practically immediately after painting.
When scheduling another update after that, don't assume that if the next
calculated update is not the immediate next update, schedule an update
sooner, as that will in such cases always be true, meaning we ended up
busy looping with constant frame updates being scheduled.
Fix this by only triggering that logic if the last presentation time was
actually vsync:ed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3803>
When cloning an actor we were applying a global scale to it, based on
the size of the clone itself and of the cloned actor.
This implied that the transformed size of the clone was not the one that
was set, but it was taking taking in account the actor scaling too.
So in practice we were scaling it twice.
While this had no visual implications it indeed was causing troubles
when a ClutterClone was reactive because in such case only the scaled
area of the scaled clone was considered reactive.
Assume you had an actor of 100x100 pixels, scaling it to a clone of
50x50 pixels:
- The scale applied to the clone was 0.5
- The transformed size of the clone was: 25x25 pixels
- The clone was reactive only in that sub-area
To avoid this, never touch the clone transformation matrix, but only
transform it at paint time.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2959>
ClutterInputMethods content hint or purpose will be set again (even to the
same values) whenever a wayland client sends us a new content type/purpose.
Gtk appears to always set a content purpose on wl_text_input changes, so we
currently set and notify the "content-purpose" property on every change in a
gtk text field.
Since the OSK is gnome-shell listens to this property and re-generates its
entire layout when the content-purpose prop gets notified, this is currently
causing lag/freezes on every keypress in the OSK in gnome-shell.
So ensure to not notify these properties in case they're equal and set the
properties in the same way as we usually set them instead of going via
GObject.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3645>
Gestures are independent from each other when they are on different
actors and when they don't have a conflict over input with each other: For
example a gesture on one window and a gesture on another window will
recognize at the same time perfectly fine right now.
For those gestures (let's call them "independent gestures") we don't want
to control how the conflicting input should be handled, i.e. whether one
gesture wins over another or whether both can be recognizing using the
same touchpoint (e.g. zoom+rotate on the same actor). Instead we want
to control whether they are allowed to start while another one is running.
For now, make it impossible for two gestures to recognize globally at
the same time in all cases. This helps prevent subtle bugs and makes life
easier for users of the API. We can introduce API for fine grained control
over the behavior later.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2389>
With the next commit, we'll need a list of all gestures that currently are
active globally. Since actors and actions (and therefore also gestures) in
Clutter are bound to a stage, it makes sense for this list to exist on the
ClutterStage level.
The list itself is a simple GPtrArray (to allow for quick searches) that
doesn't reference the gestures and is not manipulated by the stage itself.
All manipulation of the array is left to ClutterGestures.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2389>
Quite often there are situations where multiple gestures try to
recognize, keeping track of the same set of points (for example an edge
drag gesture on the stage and a click gesture somewhere in the
scenegraph). Usually what's wanted here is that the first gesture to
move to RECOGNIZING wins over all other active gestures and "claims" the
point for itself.
We implement this by introducing a concept called "influencing". It
works by making all gestures operating on a shared set of points aware
of each other using ClutterAction->register_sequence().
ClutterGesture uses this vfunc to keep track of all other
ClutterGestures that are potentially conflicting, and keeps a list
(priv->cancel_on_recognizing) of those. As soon as the move to
RECOGNIZING happens, all gestures inside this list get moved to
CANCELLED.
To allow fine-grained control over this behavior, two APIs are
introduced:
1) on the implementation level (should_influence() and
should_be_influenced_by()): This is a vfunc that gets called as soon as
a potential conflict is detected. It's helpful when a specific gesture
always behaves the same towards another gesture, for example to make
sure a LongPress gesture never cancels a DragGesture.
2) on the gesture user level, clutter_gesture_can_not_cancel() is
introduced: This allows control for the user of a gesture to specify
that a specific instance of a gesture won't cancel another gesture.
Calling this twice so that both gestures can't cancel each other allows
for things like simultaneous recognition of a pinch-to-zoom and rotate
gesture.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2389>
Introduce ClutterGesture, a new ClutterAction subclass and the successor
of ClutterGestureAction that brings the necessary tools to handle
sequences of events and abstract touch and mouse gestures from those.
The big difference compared to ClutterGestureAction is that ClutterGesture
provides the implementation with point_added/moved/ended and
sequences_cancelled events and expects the implementation to move the
ClutterGesture through the ClutterGestureState state machine. This state
machine is then used internally by ClutterGesture to coordinate with other
gestures.
With the next commits, ClutterGesture will handle relationships between
conflicting gestures completely by itself, allowing the implementation or
the user to specify the details of the relationship between two gestures.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2389>
clutter_event_get_source() is still valid for the case of crossing events,
just like clutter_event_get_related(). The latter is not deprecated, so the
former shouldn't be either.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2389>
ClutterStage will unref an action in the middle of its own event handler in
case the action causes its own actor to be destroyed. In this case the
action would get freed underneath our feet. To avoid it, take a ref on the
action while calling its handle_event() vfunc, just as we do in
clutter_actor_event() while emitting an event to an actor.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2389>
Since commit e30eb78891 `ClutterFrameClock` assumes that a valid CPU time
implies timestamp query support, which is also checked in
`cogl_onscreen_egl_swap_buffers_with_damage()`.
Unconditionally setting the CPU time on direct scanout meant that the
compositing path would be stuck on the last (direct scanout optimized)
result on GL implementations without timestamp query support since.
be0aa2976e (clutter/frame-clock: Avoid rapidly toggling dynamic max render time)
Fix that by explicitly marking the gpu rendering duration as valid when
querying the GPU timestamps is supported and check for it ClutterFrameClock.
Fixes: 56580ea7c9 ("backends/native: Assume zero rendering time for direct scanout buffers")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3655>
