Emit crossing events whenever a grab coming or going would cause a
pointer/touchpoint to become inactive on their position. Depending
on whether the pointer lies inside the old or new grab widgets,
enter or leave events would be generated.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2068>
We will want to be more specific about the portions of the actor
hierarchy that receive this event, separate creation and emission
so each place does what is relevant.
However, this commit brings no functional changes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2068>
These events are not meant to be ever silenced away, every actor
that is meant to receive one should do so. Make it sure that those
events cannot be stopped, despite the event signal handlers return
values.
This opens the debate about whether crossing events should be
ClutterEvents, since they are more and more uncommon at being one,
maybe this notification mechanism should be taken away from the
event machinery, but that's something for future refactors.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2068>
Hopefully, the one to make them all converge. This new ClutterGrab
represents a handle on a created grab. These are stacked, so grabs
can be overridden and remain inactive until there is a time that
they become active again, although undoing these early is optional.
These grabs are global, they do apply to all pointer, touchpoint
and keyboard foci.
At the moment, only the API to create and stack those is added,
the actual functionality is added in future commits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2068>
A property for reversing the visible order of children is a bit odd.
It has also been unused by actual gnome-shell code since 2010, and the
somewhat related pack_start()/pack_end() API in GtkBox(Layout) is gone
in GTK4.
With that in mind, turn the property into a no-op and deprecate it,
so that it can be dropped next cycle.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2206>
This ensures they remain perfectly smooth regardless of how the
dispatch time has been adjusted/optimized/delayed/jittered.
Idea by Ivan Molodetskikh <yalterz@gmail.com>
For example, dragging a window on a 60Hz monitor:
BEFORE
delta(time_us) = 17014μs
delta(time_us) = 15998μs
delta(time_us) = 17006μs
delta(time_us) = 16975μs
delta(time_us) = 16001μs
delta(time_us) = 17002μs
delta(time_us) = 17006μs
delta(time_us) = 16004μs
AFTER
delta(time_us) = 16667μs
delta(time_us) = 16667μs
delta(time_us) = 16670μs
delta(time_us) = 16667μs
delta(time_us) = 16669μs
delta(time_us) = 16668μs
delta(time_us) = 16664μs
delta(time_us) = 16674μs
Caveat 1: Because we don't know a "next presentation time" on the first
frame, the interval between the first and second frame will usually be
different to the subsequent steady interval. So this change increases the
jitter of just frame 2, but eliminates jitter thereafter.
Caveat 2: `clutter_frame_clock_schedule_update_now` schedules updates
earlier than `clutter_frame_clock_schedule_update`. This means potentially
you could get multiple frames targeting the same "next presentation time".
That doesn't really change here though - we're dispatching at the same
times as we used to and just giving timelines a better vsync-aligned
timestamp now.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/25
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2161>
This won't change anything for 60Hz displays but higher refresh rate
users will benefit.
Using Nvidia EGLStreams on a 240Hz monitor for example (refresh interval
~4.1ms), the maximum render time allowed before dropping to 120Hz is now
3.6ms whereas it was previously 2.1ms.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2158>
This is notably necessary with transformations, since these don't
trigger allocation machinery, but may affect the actor under the
pointer.
Visible e.g. with GNOME Shell's "Application does not respond"
dialogs.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
With Wayland handling all events as they come, this code now just
performs motion compression for events that will be handled by Clutter
widgetry.
The intent to opt tablets and styli out of motion compression was
early and fast client handling, since that is now covered in a generic
manner, this code is superfluous. We don't really need the extra events
for these devices in compositor widgetry either.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
We essentially create those at the time they need to be handled, and
use shortcuts that avoid the event from being queued up. It's too much
of a short cut though, these events are also of interest to the Wayland
event handlers, e.g. to handle pointer state changes (e.g. repicks due
to the pick actor being destroyed) immediately, instead of at the next
event.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
If we are still under the "clear area" of the pick actor, we forget
to update the coordinates. This is usually not needed, unless we
need to repick again for non-event circumstances (e.g. pick actor
is destroyed). This will ensure the right pointer coordinates are
used afterwards in those situations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
Traditionally, the next repaint would also involve picking, which
would correct the actor under the pointer. This now does not happen
out of the box, so we really are waiting for the next pointer event
here.
To avoid the pointer/cursor to lag behind, trigger an immediate
repick here, that will look up the new actor under the pointer
coordinates.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
And resort to it first, unless we are told to ignore the cache
(e.g. after relayouts). This avoids further pick context operations
while the pointer is on the current actor.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
This safe area is the region (in stage coordinates) where the pointer
is ensured to stay within the current actor. This is not used yet, but
will be used for optimizations in pointer picking.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
These may be used for optimizations once we find the pick actor,
so picking can be avoided in areas we know didn't cross into
other actors. Nothing makes use of it yet though, just log these
so far.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
Add a clutter_stage_pick_and_update_device() method that is the only
single entry point for updating a device position as seen by the
stage.
Also, update all callers to use it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
The clutter_stage_get_actor_at_pos() calls it almost 1:1 underneath
and is public API, we can have all callers use this, and stop using
this function outside of clutter-stage.c.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
As event handling goes:
1) Events get generated and queued by the seat (from another thread in
native, in the same thread in X11)
2) The MetaBackend gets those events and forwards them to Clutter
via clutter_do_event()
3) The events get queued in the ClutterStage
4) At the time of processing a frame, the input events are processed,
5) Motion events are throttled, only the last is effectively handled
6) Events are filtered, wayland and WM handling happens here
7) Events maybe reach to clutter
This commit moves 6 to happen between 2 and 3. The end result is that:
- Throttling only applies to Clutter event handling, The wayland event
forwarding bits will handle the event stream as soon as it comes, as
timely as possible.
- WM event handling is also unthrottled, but that's more of a side
effect.
- This all still happens on the main thread, so there's the possibility
that other busy areas (e.g. relayout) temporarily block this event
forwarding.
- Sending events unthrottled inherently means more CPU, probably
dependent on input devices' frequency. The impact is not measured.
This should bring the best of both worlds with e.g. 1000Hz mice, wayland
clients get unthrottled events, while GNOME Shell UI still behaves like
it used to do.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
If we wait till finalize, dispose will destroy the actor hierarchy
and cause untimely repicks. Ensure to free the pointer/touch info
first, so the hooked signal callbacks are gone when destroying the
actors.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
In the case a11y is required, the screen reader is very much
interested in getting an uninterrupted flow of key events. It attempts
so by setting a ::captured-event callback on the ClutterStage, but
that falls short with our MetaDisplay event handler, as clutter events
can be stopped before a11y gets a chance to see them.
This kind of selective amnesia wrt key events is not new, in X11 those
go unheard of by the WM as long as a client is focused and no grabs hold,
so it is clients' responsibility to talk with AT bridge.
This commit doesn't yet change that for X11, but we can do this right
away from the compositor on Wayland, and without any chance to be
tampered by clients.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1328>
If one would end up with an actor attached to mapped actor, where the
attached actor doesn't itself have an up to date stage view list while
listening on the stage for updating, when clearing the stage views of
the list, anything that would query the stage views list at this time
would end up accessing freed memory.
This could happen if
1) An actor was added to a newly created container actor attached to
the stage
2) The actor got a timeline attached to it
3) The actor was moved to a container that already was mapped
4) A hotplug happened
After (1) both the container and actor would not have any stage views.
After (2) the timeline would listen on the stage for stage views
updates. After (3) the actor would still listen on the stage for stage
views updates. When (4) happened, the actor would be signalled when the
stage got its stage view cleared, at which point it would traverse up
its actor's tree finding an appropriate stage view to base its animation
on. The problem here would be that it'd query the already mapped
container and its yet-to-be-cleared stage view list, resulting in
use-after free, resulting in for example the following backtrace:
0) g_type_check_instance_cast ()
1) CLUTTER_STAGE_VIEW ()
2) clutter_actor_pick_frame_clock ()
3) clutter_actor_pick_frame_clock ()
4) update_frame_clock ()
5) on_frame_clock_actor_stage_views_changed ()
6) g_closure_invoke ()
7) signal_emit_unlocked_R ()
8) g_signal_emit_valist ()
9) g_signal_emit ()
10) clear_stage_views_cb ()
11) _clutter_actor_traverse_depth ()
12) _clutter_actor_traverse ()
13) clutter_actor_clear_stage_views_recursive ()
14) clutter_stage_clear_stage_views ()
...
Avoid this issue by making sure that we don't emit 'stage-views-changed'
signals while the actor tree is in an invalid state. While we now end up
traversing tree twice, it doesn't change the Big-O notation. It has not
been measured whether this has any noticible performance impact.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1950
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2025>
This does two things to frown upon:
- Modifies ClutterEvent structs, while the effort is to have those
completely opaque, and readonly after creation from the input
thread side.
- Stores state in the ClutterInputDevice struct, event though those
are also considered static after creation, managed by the input
thread, etc.
Stop doing that. This makes all events just forwarded as-is in
the ClutterStage/clutter-main.c code.
Handling of click count sounds like material for a ClutterGestureAction
(or perhaps ClutterClickAction), all of both callers now do it in place
at the moment, while gestures lack a better state tracking and management.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2024>
This will not try the captured-event shenanigans to emulate grab
behavior, instead relying on event delivery being influenced by
other grab mechanisms.
While at it, improve handling of additional touchpoints by
cancelling the click action right away, as the differences in
event handling make this unwanted behavior surface.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2024>
By default, the pan action performs matrix translations on the
child widget. Nobody wants that (or, nobody wants *just* that).
It's cleaner not to mix mechanism and effect in ClutterGestureAction
subclasses, so drop this base implementation, and change the signal
accumulator so it's more similar to event signals (not that it's
used any longer, anyway).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2024>
This warning is actually dead code, since should_be_mapped and
must_be_realized are always set to the same value, so it does not
make sense to check for "a && !b".
Turn this into an assert so we avoid the dead branch, but do not
remove the variable duplication so the more aptly named variable
is used where it belongs, for clarity.
CID: #1506254
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2061>
It was a feature relevant for when Clutter was an application toolkit
that wanted the application window to communicate a minimum size to the
windowing system.
Now, clutter is part of the windowing system component, so this feature
doesn't make any sense, so remove it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2002>
This feature was configured depending on whether the Cogl backend
reported COGL_WINSYS_FEATURE_MULTIPLE_ONSCREEN or not. All cogl backends
do report this, so any code handled the 'static' case were never used.
While we only ever use one stage, it's arguable more correct to
consilidate on the single stage case, but multiple stages is something
that might be desirable for e.g. a remote lock screen, so lets keep this
logic intact.
This has the side effect of completely removing backend features, as
this was the only left-over feature detection that they handled.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2002>
This changes the setup phase of clutter to not be result of calling an
init function that sets up a few global singletons, via global singleton
setup vfuncs.
The way it worked was that mutter first did some initial setup
(connecting to the X11 server), then set a "custom backend" setup vfunc
global, before calling clutter_init().
During the clutter_init() call, the context and backend was setup by
calling the global singleton getters, which implicitly created the
backend and context on-demand.
This has now changed to mutter explicitly creating a `ClutterContext`
(which is actually a `ClutterMainContext`, but with the name shortened to
be consistent with `CoglContext` and `MetaContext`), calling it with a
backend constructor vfunc and user data pointer.
This function now explicitly creates the backend, without having to go
via the previously set global vfunc.
This changes the behavior of some "get_default()" like functions, which
will now fail if called after mutter has shut down, as when it does so,
it now destroys the backends and contexts, not only its own, but the
clutter ones too.
The "ownership" of the clutter backend is also moved to
`ClutterContext`, and MetaBackend is changed to fetch it via the clutter
context.
This also removed the unused option parsing that existed in clutter.
In some places, NULL checks for fetching the clutter context, or
backend, and fetching the cogl context from the clutter backend, had to
be added.
The reason for this is that some code that handles EGL contexts attempts
to restore the cogl EGL context tracking so that the right EGL context
is used by cogl the next time. This makes no sense to do before Cogl and
Clutter are even initialized, which was the case. It wasn't noticed
because the relevant singletons were initialized on demand via their
"getters".
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2002>
This one is a trivial wrapper around clutter_actor_get_children(), so just
use that in the two places where clutter_container_get_children() is used,
and remove clutter_container_get_children().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2057>
Right now we damage the stage even if an actor is not mapped, for
example in the overview.
Stop doing so, reducing over-paint significantly in some situations.
Clones will still do stage damage on their own.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2035>
ClutterText implements its own get_paint_volume() with its own cache,
but was not invalidating the actor paint volume when when it has
changed. This sometimes could result in labels, especially quickly
changing ones, using the old paint volume which either would cut off the
label or leave parts of the old label on screen.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1943
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2006>
This mode is passed along by the ClutterInputMethod, the
ClutterInputFocus will preserve it and ensure it is honored
whenever the IM is being reset.
This mode is immediate. The ClutterInputFocus commits the
text directly without queueing a CLUTTER_IM_COMMIT event.
This is important so events are serialized in the right order
in the wayland implementations (i.e. commit before wl_pointer.press).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1940>
In line with GTK, the input method context should be reset when clicks
are handled by the ClutterInputFocus user. The reset action can then
either clear or commit the preedit text, as configured by the IM module.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1940>
Make sure that when we've recreated views that we'll actually paint a
new frame for it. This was very rarely a problem, as views tend to
result in getting damage etc being queued as side effects of various
things, like layout, but e.g. when running certain tests, this might not
happen. There is no situation where we want to create a new view that
should remain unpainted, so just make sure we initialize it to become up
to date.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1947>
This code sneaked unconditionally, even though we can disable
tracing code with -Dprofiler=false. Add some COGL_HAS_TRACING
checks so that this code is also optionally built.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1951>
Will be used to trace a lot more, and with more details, and thus may
have a larger impact on what is actually measured. This potential impact
is the reason for enabling only when needed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1700>
The failure to allocate was not properly handled, causing crashes later
on due to the offscreen being NULL.
#0 cogl_gl_framebuffer_bind (target=36160, gl_framebuffer=0x0)
#1 _cogl_driver_gl_flush_framebuffer_state (...)
#2 cogl_context_flush_framebuffer_state (read_buffer=0x55f48f386780, draw_buffer=0x55f48f386780, ...)
#3 cogl_framebuffer_clear4f (framebuffer=0x55f48f386780, ...)
#4 clutter_layer_node_pre_draw (...)
#5 clutter_paint_node_paint (...)
...
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1942>
We only listen to it for 2 settings (drag threshold, double click
time), and we already have the stock ClutterSettings object tracking
the source of these. This code is redundant.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1862>
Not sure how to update the damage or redraw clip or something; at least
this works properly when under a constantly-redrawing window, which is
ok for debugging purposes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1762>
Max render time shows how early the frame clock needs to be dispatched
to make it to the predicted next presentation time. Before this commit
it was set to refresh interval minus 2 ms. This means Mutter would
always start compositing 14.7 ms before a display refresh on a 60 Hz
screen or 4.9 ms before a display refresh on a 144 Hz screen. However,
Mutter frequently does not need as much time to finish compositing and
submit buffer to KMS:
max render time
/------------\
---|---------------|---------------|---> presentations
D----S D--S
D - frame clock dispatch
S - buffer submission
This commit aims to automatically compute a shorter max render time to
make Mutter start compositing as late as possible (but still making it
in time for the presentation):
max render time
/-----\
---|---------------|---------------|---> presentations
D----S D--S
Why is this better? First of all, Mutter gets application contents to
draw at the time when compositing starts. If new application buffer
arrives after the compositing has started, but before the next
presentation, it won't make it on screen:
---|---------------|---------------|---> presentations
D----S D--S
A-------------X----------->
^ doesn't make it for this presentation
A - application buffer commit
X - application buffer sampled by Mutter
Here the application committed just a few ms too late and didn't make on
screen until the next presentation. If compositing starts later in the
frame cycle, applications can commit buffers closer to the presentation.
These buffers will be more up-to-date thereby reducing input latency.
---|---------------|---------------|---> presentations
D----S D--S
A----X---->
^ made it!
Moreover, applications are recommended to render their frames on frame
callbacks, which Mutter sends right after compositing is done. Since
this commit delays the compositing, it also reduces the latency for
applications drawing on frame callbacks. Compare:
---|---------------|---------------|---> presentations
D----S D--S
F--A-------X----------->
\____________________/
latency
---|---------------|---------------|---> presentations
D----S D--S
F--A-------X---->
\_____________/
less latency
F - frame callback received, application starts rendering
So how do we actually estimate max render time? We want it to be as low
as possible, but still large enough so as not to miss any frames by
accident:
max render time
/-----\
---|---------------|---------------|---> presentations
D------S------------->
oops, took a little too long
For a successful presentation, the frame needs to be submitted to KMS
and the GPU work must be completed before the vblank. This deadline can
be computed by subtracting the vblank duration (calculated from display
mode) from the predicted next presentation time.
We don't know how long compositing will take, and we also don't know how
long the GPU work will take, since clients can submit buffers with
unfinished GPU work. So we measure and estimate these values.
The frame clock dispatch can be split into two phases:
1. From start of the dispatch to all GPU commands being submitted (but
not finished)—until the call to eglSwapBuffers().
2. From eglSwapBuffers() to submitting the buffer to KMS and to GPU
work completing. These happen in parallel, and we want the latest of
the two to be done before the vblank.
We measure these three durations and store them for the last 16 frames.
The estimate for each duration is a maximum of these last 16 durations.
Usually even taking just the last frame's durations as the estimates
works well enough, but I found that screen-capturing with OBS Studio
increases duration variability enough to cause frequent missed frames
when using that method. Taking a maximum of the last 16 frames smoothes
out this variability.
The durations are naturally quite variable and the estimates aren't
perfect. To take this into account, an additional constant 2 ms is added
to the max render time.
How does it perform in practice? On my desktop with 144 Hz monitors I
get a max render time of 4–5 ms instead of the default 4.9 ms (I had
1 ms manually configured in sway) and on my laptop with a 60 Hz screen I
get a max render time of 4.8–5.5 ms instead of the default 14.7 ms (I
had 5–6 ms manually configured in sway). Weston [1] went with a 7 ms
default.
The main downside is that if there's a sudden heavy batch of work in the
compositing, which would've made it in default 14.7 ms, but doesn't make
it in reduced 6 ms, there is a delayed frame which would otherwise not
be there. Arguably, this happens rarely enough to be a good trade-off
for reduced latency. One possible solution is a "next frame is expected
to be heavy" function which manually increases max render time for the
next frame. This would avoid this single dropped frame at the start of
complex animations.
[1]: https://www.collabora.com/about-us/blog/2015/02/12/weston-repaint-scheduling/
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1762>
This fixes a warning/error:
In function 'parse_settings',
inlined from 'read_settings' at ../clutter/clutter/x11/xsettings/xsettings-client.c:398:25:
../clutter/clutter/x11/xsettings/xsettings-client.c:202:13: error: 'buffer.byte_order' may be used uninitialized [-Werror=maybe-uninitialized]
202 | if (buffer.byte_order != MSBFirst &&
| ~~~~~~^~~~~~~~~~~
This is needed to bump the CI image from F33 to F34, which includes a
upgraded compiler.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1865>
A simply wrapper around `CoglTexture`, making it easy to reuse
content without roundtrip from GPU to CPU memory and back.
It optionally takes a clip rectangle which is implemented by
creating a `CoglSubTexture`. A limitation here is that floating
point clips are not supported.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1888>
When using `CLUTTER_PAINT=damage-region` highlighting was conspicuously
absent during fullscreen animations like entering or leaving the
overview. That was because `queued_redraw_clip` was empty, because it
had been initialized from `redraw_clip == NULL` (full stage redraw).
Now we paint the damage region as the full view (which it is) instead
of nothing at all.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1890>
This commit adds scaling support to clutter_stage_capture_into, which
is currently used when screencasting monitors. This is supposed to
fix graphical issues that arise when using fractional scaling.
Fixes#1131
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1855>
All pointer a11y is a fabrication of Clutter backend-independent
code, with the help of a ClutterVirtualInputDevice and with some
UI on top.
On the other hand, MetaInputSettings is a backend implementation
detail, this has 2 gotchas:
- In the native backend, the MetaInputSettings (and pointer a11y
with it) are initialized early, before the ClutterSeat core
pointer is set up.
- Doing this from the MetaInputSettings also means another dubious
access from the input thread into main thread territory.
Move the pointer a11y into ClutterSettings, making this effectively
backend-independent business, invariably done from the main thread
and ensured to happen after seat initialization.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1765
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1849>
Since commit d2f8a30625 we use Graphene to union paint volumes, it
turns out a quite severe issue snuck in during review of that MR though:
Unioned paint volumes (so paint volumes of any actors with children) now
have negative heights. Once projected to 2d coordinates they luckily are
correct again, which is why everything is still working.
The problem is that obvious once looking closer: For the y coordinates
of the unioned paint volume we confused the maximum and the minimum
points and simply used the wrong coordinates to create the unioned paint
volume.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1827>
The graphene functions used by clutter for picking assume that boxes are
inclusive in both there start and end coordinates, so picking at y
coordinate 32 for an actor with the height 32 placed at y coordinate 0
would still be considered a hit. This however is wrong as 32 is the
first position that is not in the actor anymore.
Usually this would not be much of a problem, because motion events are
rarely ever at exactly these borders and even if they are there will be
another motion event soon after. But since actors in gnome-shell usually
are aligned with the pixel grid and on X11 enter/leave events are
generated by the X server at integer coordinates, this case is much
more likely for those.
This can cause issues with Firefox which when using client side
decorations, still requests MWM_DECOR_BORDER via _MOTIF_WM_HINTS to have
mutter draw a border + shadow. This means that the Firefox window even
when using CSD is still reparented. For such windows we receive among
others XI_RawMotion and XI_Enter events, but no XI_Motion events. And
the raw motion events are discarded after an enter event, because that
sets has_pointer_focus to TRUE in MetaSeatX11. So when moving the cursor
from the panel to a maximized Firefox window the last event clutter
receives is the enter event at exactly integer coordinates. Since the
panel is 32px tall and the generated enter event is at y position 32,
the picking code will pick a panel actor and the focus will remain on it
as long as the cursor does not leave the Firefox window.
Fix this by excluding the bottom and right border of a box when picking.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4041
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1842>
Turns out ClutterClones need a bit of extra handling as always, there's
currently nothing that invalidates a clones paint volume when the source
actors paint volume changes.
Since ClutterClones get_paint_volume() implementation simply takes the
source actors paint volume and returns that, we should make sure they
are kept in sync and invalidate the clones paint volume as soon as the
source actor gets its PV invalidated.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1829>
Updating the last_paint_volume while painting has proven itself to be
quite prone to issues: First we had to make sure actors painted by
offscreen effects get their last_paint_volumes updated correctly (see
0320649a1c), and now a new issue turned up
where we don't update the paint volumes while a fullscreen unredirect is
happening.
To stop those issues from happening and to lay the foundation for using
the last_paint_volume for other things, update the last_paint_volume in
a separate step before painting instead of doing it in
clutter_actor_paint().
To save some resources, avoid introducing another traversal of the
scenegraph and add that step into the existing step of updating the
stage_views lists of actors. To properly update the paint volumes, we
need to do that after finishing the queued redraws, which is why we move
clutter_stage_maybe_finish_queue_redraws() to happen before the new
clutter_stage_finish_layout().
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1699
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1773>
The priv->paint_volume field of ClutterActor stores the cached paint
volume in the actors local coordinate system. It consist of the actors
paint volume itself and the union of all children paint volumes.
We want to invalidate those cached paint volumes according to the
following rules:
- If an actors transformation matrix changes, all paint volumes of the
parent-tree need to be invalidated (that's because the parent-volumes
have unioned the actors paint volume). Our own paint volume does not
need invalidation since the transformation matrix is not applied to it.
- If an actors allocation-size changes, its own paint volume and all the
volumes of the parent-tree need to be invalidated. That's because the
allocation-size is used as the size of the paint volume.
- If a clip gets set or clip_to_allocation gets enabled for an actor,
its own paint volume and all the volumes of the parent-tree need to be
invalidated. That's because the clip is factored in when creating the
paint volume.
So far we did this invalidation in various places and the invalidation
up the parent-tree happened inside clutter_actor_real_queue_relayout().
We did not invalidate on changes to the actors transformation matrices
and the invalidation in clutter_actor_real_queue_relayout() was more
like a "big hammer" that probably invalidated unnecessarily a few times.
So introduce proper infrastructure to invalidate those cached paint
volumes of actors only in the cases where they actually need to be
invalidated. To do that, we reuse the transform_changed() function and
introduce a new function queue_update_paint_volume() that invalidates
the paint volumes up the actor tree.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1773>
ClutterActors can override the get_paint_volume() vfunc in case they
draw outside the allocation. That's used by a bunch of actors, for
example ClutterText or StViewport in gnome-shell.
In case of StViewport, the paint volume returned depends on the value of
the StAdjustment, which means when we start to cache paint volumes more
agressively in ClutterActor, we'll need to add API that allows
StViewport to invalidate the paint volume. So introduce
clutter_actor_invalidate_paint_volume() to invalidate the cached paint
volume.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1773>
The action might not have been triggered yet, as per its trigger
threshold. This doesn't mean we shouldn't reset the point(s) accumulated
so far.
This fixes those touchpoints persisting after disable/enable, thus
making gesture recognition fail from there on.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1791>
We might want to perform distance/threshold checks in the ::prepare
vfunc, but we didn't record the last motion event yet. This used to
give a delta of 0/0 between the press and last motion coordinates,
despite the ClutterGestureAction having a trigger threshold. This
happens no longer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1791>
The usage of clutter_actor_get_preferred_width/height() for building the
pick box can trigger Clutters size negotiation machinery in case the
allocation of the actor is invalidated, with commit 82f3bdd1 we worked
around that by excluding actors with invalidated allocations from
picking.
There's no need to do that though, when picking we always want to
operate on the last known allocation of the actor, since that is what's
actually painted on the screen.
So instead of not picking at all when an actors allocation is
invalidated, just use the size of the last allocation. We still have to
factor in one extra case, that's when an actor hasn't gotten any
allocation yet: In that case we want to exclude the actor from picking
since the actor is not on the screen yet.
This fixes a regression introduced by the commit mentioned above where
picking wouldn't work on windows that have just been resized.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1674
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1784>
As documented in g_once_init_enter(): "While @location has a volatile qualifier,
this is a historical artifact and the pointer passed to it should not be
volatile.". And effectively this now warns with modern glibc.
Drop the "volatile" qualifier from these static variables as it's expected.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1785>
Some events such as the proximity one requires a device to be set before
we process them, so ensure we process the event details after we've
added the device to the seat.
This may lead to handle a device-removed signal before the clutter event
but it's anyways not different from what we did before commit 012c0a18
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1779>
The CallyStage objects lifetime is tied to the stage, so if we add a
weak pointer to it, we won't be able to remove it, as we would try to do
so not until the stage itself is being disposed, at which point removing
it fails. However, not removing it will make the stage try to clean up
the weak refs, and since it does this more or less directly after
freeing the cally stage, it ends up writing NULL to freed memory,
causing memory corruption.
Fix this by avoiding adding the weak pointer when that pointer is to the
stage.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1775>
This adds a test framework that makes it possible to compare the result
of painting a view against a reference image. Test reference as PNG
images are stored in src/tests/ref-tests/.
Reference images needs to be created for testing to be able to succeed.
Adding a test reference image is done using the
`MUTTER_REF_TEST_UPDATE` environment variable. See meta-ref-test.c for
details.
The image comparison code is largely based on the reference image test
framework in weston; see meta-ref-test.c for details.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
Since commit 2ceac4a device-related X11 events aren't processed anymore,
causing the input settings not to handle the devices.
This is due to the fact that we may never call clutter_seat_handle_event_post()
for such events.
While this is always happening for the native backend, it doesn't happen in
X11 because the events are removed from the queue as part of
meta_x11_handle_event(), and thus no event was queued to the stage by the
backend events source.
This also makes sure that the event post handler is called after the
event is actually processed, and not before an event is queued.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1564
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1769>
To make the double buffered shadow buffer damaged tiles detection
feasable, a new EGL extension is needed for creating FBO's backed by
a custom CPU memory buffer, instead of DMA buffers, as DMA buffers can
be very slow to read, much slower than just painting the shadow buffer
directly.
Leave the code there, since such an EGL extension is intended to be
added, but hide it behind an env var so that it isn't enabled by
accident.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1724>
Regarding the sequence = 0 fallback: in some cases (moving a cursor
plane on atomic amdgpu) we get sequence = 0 in the page flip callback.
This seems like an amdgpu bug, so work around it by assuming a sequence
delta of 1 (it is equal to 1 because of the sequence != 0 check above).
Sequence can also legitimately be 0 if we're lucky during the 32-bit
overflow, in which case assuming a delta of 1 will give more or less
reasonable values on this and next presentation, after which it'll be
back to normal.
Sequence is also 0 on mode set fallback and when running nested, in
which case assuming a delta of 1 every frame is the best we can do.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
This concerns only the cases when the presentation timestamp is received
directly from the device (from KMS or from GLX). In the majority of
cases this timestamp is already MONOTONIC. When it isn't, after this
commit, the current value of the MONOTONIC clock is sampled instead.
The alternative is to store the clock id alongside the timestamp, with
possible values of MONOTONIC, REALTIME (from KMS) and GETTIMEOFDAY (from
GLX; this might be the same as REALTIME, I'm not sure), and then
"convert" the timestamp to MONOTONIC when needed. An example of such a
conversion was done in compositor.c (removed in this commit). It would
also be needed for the presentation-time Wayland protocol. However, it
seems that the vast majority of up-to-date systems are using MONOTONIC
anyway, making this effort not justified.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
KMS and GLX device timestamps have microsecond precision, and whenever
we sample the time ourselves it's not the real presentation time anyway,
so nanosecond precision for that case is unnecessary.
The presentation timestamp in ClutterFrameInfo is in microseconds, too,
so this commit makes them have the same precision.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
A flag indicating whether the presentation timestamp was provided by
the display hardware (rather than sampled in user space).
It will be used for the presentation-time Wayland protocol.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
ClutterText has a bit of a mess around its signalling of changes to the
cursor position: There's the position (deprecated) and cursor-position
property, and there's the cursor-changed and cursor-event (deprecated)
signal. The two properties are supposed to be notified when the cursor
position changes, and the two signals are notified when the cursor
position or size changes.
Now the properties notifications and the signals get fired in two very
different places: The two properties are notified in
clutter_text_set_cursor_position(), while the signals are fired during
the paint cycle when we figured out the final cursor position. The
latter is a pretty bad idea, nobody expects such a signal to be fired
during painting, and also changes to the text that are done in the
signal handler will only be applied on the next paint.
Now StEntry listens to cursor position changes via cursor-changed and
invalidates its text shadow, but since the signal is only notified
during the paint, the old text shadow will still get applied. To fix
this, also emit the cursor-changed signal when we notify the
cursor-position property.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1757>
This removes the responsibility of tracking these from the backend to
the base object. The backends are instead responsible for calling the
function to update the values.
For the native backend, it's important that this happens on the correct
thread, so each time either of these states may change, post a idle
callback on the main thread that sets the, at the time of queuing said
callback, up to date state. This means that things on the main thread
will always be able to get a "new enough but not too new" state when
listening on the 'notify::' signals and getting the property value
after.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1739>
In an x11 session, we don't receive motion events from X when the
pointer is above a window. Since commit 734a1859 we only do picking on
motion events though, which means when clicking the mouse to focus a
window, we don't repick and might still think the pointer is hovering
above another window or actor, ending up not focussing the window.
Fix this by always repicking on BUTTON_PRESS events. While this is not
necessary in the wayland session, button presses happen rarely compared
to motion events, so it's not a performance regression to do it in
Wayland sessions, too.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1660
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1752>
ClutterText allows setting a custom PangoAttrList, and St uses that to
set the text style it's reading from CSS. One style St enforces using
this mechanism is the text color and setting the text color should
obviously not affect the size of the layout. ClutterText does queue a
relayout in that case though because it unconditionally queues a
relayout when updating the PangoAttrList.
We can avoid this relayout by reusing an optimization ClutterText has:
clutter_text_queue_redraw_or_relayout() will only queue a relayout if
the requested size of the layout changed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1750>
With 734a185915 an optimization was
introduced to only pick on events which can actually cause the pointer
to move. In case of touch events, the first event (TOUCH_BEGIN) will
already move the touchpoint though, and we'll send our crossing
CLUTTER_ENTER event to the actor this TOUCH_BEGIN happened on.
So fix this embarrassing bug that caused touch input to break by also
picking to find an event-actor on TOUCH_BEGIN events.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1733>
Aside from ENTER/LEAVE, there are only two kinds of events that can move
the pointer, motion events and touch update events. Everything else
keeps the pointer at it's current position.
The reason we pick inside _clutter_process_event_details() is that we
want to set the event actor. Now if an event can't move the pointer, it
also can't change the event actor (well, it can subsequently by
triggering changes to the scenegraph, but that's handled elsewhere), so
there's no need to pick a new event actor when we get those events.
Instead, simply reuse the actor that's already associated with the
current input device as the event actor for non MOTION/TOUCH_UPDATE
events.
Events where a device or a touchpoint goes away (like DEVICE_REMOVED or
TOUCH_END/CANCEL) also affect picking, they don't need a repick, but
instead the actor associated with the device/touchpoint needs to be
unassociated. This is ensured by invoking remove_device_for_event() on
those events and will not be affected by this change.
This should improve performance while scrolling quite a bit, since
scroll events come in unthrottled and we now no longer do a repick on
each one of those.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1729>
We might have a stage view listener attached to the stage itself if the
actor didn't have a suitable frame clock when the actor was associated
with the timeline. We'd then listen to stage-views-changed signals on
the stage itself to be able to attach to a frame clock when one
appeared.
What went wrong is that if an actor that didn't have a frameclock was
associated with a timeline, but then destroyed, the timeline would
disassociate itself from the actor, but it'd still listen on the
stage-views-changed signal on the stage. This would be in itself
harmless, until the timeline itself is destroyed, as at this point, it
wouldn't clean up the stage-views-changed listener on the stage, as it's
assumed to only be valid when there is an actor attached.
Fix this issue by cleaning up the stage's stage-views-changed listener
when the actor is destroyed, as we wouldn't be able to make use of it by
then anyway.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3323
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1719>
Before this commit, next presentation time could end up behind now_us or
ahead of now_us depending on how presentation times happened to be
aligned relative to integer multiples of refresh_interval_us. It's not
clear whether this was originally intended because even if it the next
presentation time ends up behind now_us, it is moved ahead by a while
loop down below in this function.
Even though this difference in behavior didn't really matter, it made
reasoning about the subsequent branches more complex. It would also
potentially introduce bugs if the logic was to be modified. So this
commit makes it so next presentation time is always ahead of now_us.
It also adds a comment with a graph detailing the computations, and
adjusts the variable names to drop unfortunate terminology mistakes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1707>
Last presentation time is mainly used to make sure predicted
presentation time is aligned with display refreshes. Even if it went
back in time, there will be no issue as next presentation time takes
current time into account. Synthetic presentation time is not exactly
aligned with display refreshes, so using it would only result in
inconsistent animations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1707>
When a transfer request is done to the MetaSelectionSourceRemote source,
it's translated to a SelectionTransfer signal, which the remote desktop
server is supposed to respond to with SelectionWrite.
A timeout (set to 15 seconds) is added to handle too long timeouts,
which cancels the transfer request.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1552>
Previously we were setting the FBO's viewport to be the same dimensions as
the stage itself for compatibility. This works for most cases, but not if
the actor is larger than the stage. In that case it could cause excessive
clipping if the actor's transformed screen position was negative, which
is seen in https://gitlab.gnome.org/GNOME/gnome-shell/issues/2087
Also if a small actor paints to its negative dimensions (like a box-shadow)
then we might be missing those pixels on the left or top, even though
they're inside the paint volume.
Now we set the viewport dimensions to match the area we're actually
rendering so the FBO contents are never over or under clipped.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3068
Although if you try using shadows larger than that (like in
gnome-shell#1090) then you will also need gnome-shell!1417.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1053>
We had been doing it backwards as far back as e3966882e8 which meant
that we were translating by `fbo_offset / resource_scale` stage units
instead of just `fbo_offset`.
Because `fbo_offset` is in stage units already, it's not scaled and so
needs to be applied after the unscaling from texels to stage units.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1053>
We've inherited, and still keep in place, code that reads ini files
at ~/.config/clutter-1.0/settings.ini and /etc/clutter-1.0/settings.ini
to tweak different aspects of Clutter.
Some of these should use GSettings instead, some others are exposed
nowadays differently for our purposes (e.g. envvars, looking glass, ...).
Overall seems like an unexpected entry point nowadays, so remove the
parsing of these .ini files altogether.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1693>
If we are about to replace `redraw_clip` with a clamped version of itself
then we may as well do the same for `queued_redraw_clip`, so you can see
more precisely what the damage of the current frame is.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1554>
Initially we generate the new part of fb_clip_region from the new part
of redraw_clip, scale it up and clamp. But the clamping means the new
part of fb_clip_region might now represent a slightly larger area than
the new part of redraw_clip, by one pixel.
In some rare cases where a foreground actor honours redraw_clip, but
the background actor does not (meaning it might fill all fb_clip_region),
you could find 1px rendering glitches in that gap as the background
actor paints there but the foreground actor does not.
To ensure such glitches can never happen we now regenerate the final
redraw_clip as a clamped superset of the final fb_clip_region. That's
the minimum area we must paint to ensure no gaps appear inside
fb_clip_region.
Although the fix here sounds like the intent of the old code, the old
code forgot to include the new part of fb_clip_region in the clamping
of the final redraw_clip. So the new part of redraw_clip was sometimes
kept too small for the new part of fb_clip_region.
We also move the code to the main path because technically it's also
needed when `has_buffer_age == FALSE`.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1500
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1554>
Before each frame is maybe redrawn, push any new cursor KMS state to the
pending update. It'll then either be posted during the next page flip,
or when the same frame finishes, in case nothing was redrawn.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
This makes it possible to post a symbolic page flip and frame callback,
meant to be used by immediate symbolic page flip reply when emulating
cursor plane changes using legacy drmMode* functions.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Just as with the frame clock, add an API to communicate that a frame did
not result in a presentation. This can't happen yet but will when we
emulate atomic cursor plane changes using legacy drmMode API.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
In constrast to notify_presented(), notify_ready() also returns the
state machine to the idle state, but without providing new frame
information, as no frame was actually presented.
This will happen for example with the simple KMS impl backend will do a
cursor movement, which will trigger a symbolic "page flip" reply in
order to emulate atomic KMS behavior. When this happen, we should just
try to reschedule again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Don't mode set each CRTC in separate KMS updates, as reconfiguring one
CRTC might cause other CRTCs to be implicitly reset thus as well,
causing KMS return EBUSY if using atomic modesetting.
Prepare for this by compositing each CRTC first including adding steps
to the KMS update, but wait until all views has rendered at least once
before posting the initial update. After this each CRTC is posted
separately.
Using EGLStreams instead of normal page flipping seems to fail when
doing this though, so handle that the old way for the EGLStream case,
i.e. eglSwapBuffers() -> mode set with dumb buffer -> eglStream
"acquire" (resulting in page flip under the hood).
For this we also introduce a new error code so that we don't use client
buffers when doing mode sets, which could accidentally configure the
CRTC in a way that is incompatible with the primary plane buffers.
Do the same also when we're in power save mode, to only have one special
case path for this scenario in the regular swap-buffer path.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Instead of setting the frame result in the most generic layer, have the
backends do it themselves. This is necessary to communicate that a
swap-buffer call didn't really succeed completely to present the swapped
buffer, e.g. errors from KMS.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
This argument is intended to be used by clutter to be able to
communicate with the onscreen backend, that happens to be the native
backend. It will be used to pass a ClutterFrame pointer, where the
result of page flips, mode sets etc can be communicated whenever it is
available.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
ClutterFrame aims to carry information valid during dispatching a frame.
A frame may or may not include redrawing, but will always end with a
result.
A asynchronous page flip, for example, will result in a
CLUTTER_FRAME_RESULT_PENDING_PRESENTED, while a frame that only
dispatched events etc will result in CLUTTER_FRAME_RESULT_IDLE. Instead
of this being implicit, make the ClutterStageWindow implementation
handle this itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
ClutterClickEvent currently doesn't check if button press and release
happen within the drag threshold, which can be surprising sometimes.
Only emit the "clicked" signal if the button press and release happen
within the area of drag threshold.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1667>
In clutter_timeline_set_actor() we currently always unset the
priv->frame_clock pointer of the old actor when a new actor gets set.
The priv->frame_clock pointer takes a reference on the ClutterFrameClock
though, so we leak ClutterFrameClocks here.
To fix it, simply rely on update_frame_clock(), which will call
set_frame_clock_internal() unconditionally to update the
priv->frame_clock pointer for us.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1632>
Some effects such as the BrightnessContrastEffect try to skip rendering
by returning early with a FALSE return value in pre_paint() in cases
where the effect would not change the rendering. This stopped working
when effects were ported to paint nodes.
In the case of OffscreenEffects, like BrightnessContrastEffect,
pre_paint() is responsible for setting up the offscreen buffer which is
then used in paint_node(). However if pre_paint() fails, this buffer is
not created and attempting to use it will result in several error
messages and broken rendering.
Instead of trying to call paint_node() of the effect if pre_paint()
failed, just draw the actor.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1576
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1658>
When using alt-tab to switch between windows, on a key handler we
undo the compositor grab, which triggers a repick, which generates
crossing events, which are handled in place, and trigger these
reentrancy checks.
On one hand, we do intend these crossings to take effect in place,
rather than being queued (possibly after a number of already queued
events). On the other hand, we now outright discourage generating
events from random places (and hope to make it just not possible,
eventually) thus we can afford not to protect against reentrancy
caused by API misuse.
So just drop these checks, and let these crossing events be
properly handled.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1657>
This is the very same code than meta_wayland_pointer_repick(),
made part of Clutter, so triggering repicks on the same pointer
coordinates is made easy.
The intention is to remove meta_wayland_pointer_repick() in favor
of this call.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1654>
Updating the state before emitting the CLUTTER_LEAVE event allows its
handlers to query the pointer actor, and avoid getting the same actor
again. Conceptually, this makes picking more "atomic", and the events a
notification of the change.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1654>
Turns out GObject implicitly notifies all properties by default as soon
as a property setter is called, no matter if the property actually
changed or not. One can opt-out of this behavior by setting the
G_PARAM_EXPLICIT_NOTIFY flag.
So since almost all our properties get notified explicitely (well,
except ClutterActors deprecated show-on-set-parent property), set this
flag for all properties of ClutterActor and ClutterStage now. This
significantly reduces the number of notify:: signals emitted on
ClutterActors, because in gnome-shell javascript we usually set GObject
properties directly, not by going through the extra setter method.
More cleanups can be done in the future, since this flag is suitable for
almost every property in Clutter and even Mutter.
This fixes a crash where we'd hit a newly introduced assertion in
on_device_actor_reactive_changed() of ClutterStage because
notify::reactive got emitted multiple times.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1651>
Due to a few reasons currently the updating of input devices after stage
relayouts isn't working right now. Since we now have a list of pointer
devices in ClutterStage, we can simply use that list and can avoid
asking the input thread. Also we no longer need to check whether the
devices are pointer devices, since our list only consists of pointer
devices.
So switch to ClutterStages private list of pointer devices, which also
includes the core pointer (as opposed to the list returned by
clutter_seat_peek_devices()). This fixes picking after relayouts.
Note that this doesn't catch every possible change that might need a
repick, actors might also need a repick after transformation changes or
in case their custom clip has been changed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1634>
As planned and prepared with the last commits, let ClutterStage take
care of tracking input devices and their respective actors. This means
we now can remove the old infrastructure for this from
ClutterInputDevice.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1633>
We're moving keeping track of input devices and their associated actors
out of ClutterInputDevice, this commit basically adds replacements for
clutter_input_device_update() and clutter_input_device_set_actor() to
clutter-main and shuffles the internals of those functions around a bit
for clarity.
clutter_stage_update_device() is made available in clutter-mutter.h
because we need to update the actor of input devices not only from
ClutterStage (when repicking after relayout), but also from
MetaWaylandPointer (inside meta_wayland_pointer_repick()).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1633>
With the introduction of the input thread, we want to avoid modifying
ClutterInputDevices from the main thread, since they're owned and
updated by the thread.
There's one part of ClutterInputDevice that's still modified from the
main thread though, that is device-actors of pointer devices, and we're
going to move that state-tracking into ClutterStage instead.
So start that by adding the infrastructure to ClutterStage to keep track
of those things. It consists of two hashtables which associate devices
and touch sequences with actors, those hashtables get updated using
clutter_stage_update_device_entry() and
clutter_stage_remove_device_entry(), they can be queried by calling
clutter_stage_get_device_actor(), which will replace
clutter_input_device_get_actor().
clutter_stage_get_device_coords() is added and made available in
clutter-mutter.h because we need to get the coordinates when repicking
in meta_wayland_pointer_repick().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1633>
The n_steps variable corresponds to the number of *pairs* of
texture lookups that the blur shader does. For example, when
n_steps = 1, the for-loop reads 1 pixel before and 1 pixel
after the current one.
Our blur shader is heavily inspired in WebRender's blur shader,
the biggest difference being that we calculate the gaussian
samples in the fragment shader itself, and not in the vertex
shader. (This could be an improvement in performance for the
future though!)
WebRender's blur shader calculates n_steps differently than what
we currently do, though. It calculates n_step in such a way that
at least 2 steps are performed for evey non-zero sigma value.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1646>
The shader already operates on floating point sigma, and
there's just no reason for us to force it to be an unsigned
integer. It's still important that sigma must be positive
though.
Make sigma a float, and make sure it's a positive number.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1646>
Yet another way to reduce the instruction count of the fragment
shader. Passing a pair of floats once is virtually free, compared
to computing horizontal and vertical on each fragment run.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1646>
New entries indirectly added to `pending_queue_redraw` during the loop
would make our iterator invalid and cause `g_hash_table_iter_next` to
fail without having visited all elements. That was seen as assertion
failures but also likely resulted in incomplete paint clips.
Now we steal the iterator's entry before such corruption can happen,
free it manually, and reset the iterator to the beginning on every
iteration. This is actually safe and efficient because we're removing each
entry we visit. So no time is wasted in resuming from the (new) beginning
of the hash table.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1557
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1615>
Add a new pair of APIs corresponding to CoglFramebuffer's draw_rectangles()
and draw_textured_rectangles(). They're generally more performance compared
to adding multiple single-rect operations. These variants are heavily used
by GNOME Shell's CSS implementation.
The op array is built to match cogl_framebuffer_draw_textured_rectangles()
always, which means it's a series of 8 floats composed (x1 y1 x2 y2) and
(s1 t1 s2 t2). To avoid adding new struct fields to ClutterPaintOperation,
which is a performance and memory sensitive structure, simply divide the
array length by 8 (which is guaranteed to be correct).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1637>
Setting an ortho projection gives us pretty much the same result as
manually calculating the projection matrix. The ortho projection is
actually more "complete" than the custom projection we've been using,
as it also considers z-near and z-far, but in practice the generated
pixels are exactly equal.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1642>
In the purely paint node based rendering future, ClutterEffects
simply add more paint nodes to the tree when painting the actor.
This is the leap to achieve that future.
Add paint nodes to pre_paint, paint, and post_paint, and move the
ClutterEffectNode creation to _clutter_effect_paint().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1355>
The paint node tree that ClutterOffscreenEffect generates is
simple:
Root
|------------+
| |
Layer Pipeline
|
Actor
Right now, both pre-paint and ClutterLayerNode push the offscreen
to the framebuffer stack. That's harmless, and will go away soon
anyway.
The actor node is created and added in a separate function because
it'll be reused by the next commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1355>
Add a new ClutterPaintNode parameter to the paint_target() vfunc.
For now, create a temporary ClutterEffectNode that is passed to
paint_target() and immediately painted; next commits will move
this to upper layers.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1355>
The blur pipeline is still cached on ClutterBlurEffect, and we
simply update the uniforms when asked to create the pipeline.
Now that ClutterOffscreenEffect will use the blur pipeline, it
doesn't need to override the paint_target() vfunc anymore.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1355>
The most annoying aspect of ClutterOffscreenEffect right now, and
the reason for all its subclasses to override pre-paint, is that
the pipeline creation isn't under subclasses' control. That means
all subclasses must ask ClutterOffscreenEffect to run pre-paint
and create the pipeline, then they all create their own pipelines
to paint.
To reduce this complexity, add a new create_pipeline() vfunc to
ClutterOffscreenEffect. Next commits will port effects to use this
new vfunc.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1355>
ClutterLayerNode currently skips pushing the offscreen framebuffer when
no operations are set. This was added at the time because pushing and
popping was a synchronization point in Cogl, slow enough to force the
layer node to have this protective measure. Nowadays, pushing and
popping on the paint context is free.
Make ClutterLayerNode always push and pop in pre and post paint.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1355>
ClutterBlurNode is a paint node based on ClutterLayerNode
that draws all children in an offscreen framebuffer, blurs
this framebuffer, and finally paints the blurred contents
according the the paint operations added.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1627>
Copy-paste error sneaked ClutterTransformNodeClass in
clutter_blit_node_class_init(). It wasn't problematic
because they both typedef to ClutterPaintNodeClass, but
fix it anyway.
Also switch to g_object_ref() in clutter_blit_node_new().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1627>
Until now we would `clutter_input_focus_set_cursor_location` with
cursor-rectangle-in-physical-pixels + actor-location-in-stage-coordinates.
But those use different scaling factors so it only got the right answer
when the framebuffer scale was 1.0.
This directly determines the geometry of the invisible dummy cursor in
gnome-shell ibusCandidatePopup.js:
```
panelService.connect('set-cursor-location', (ps, x, y, w, h) => {
this._setDummyCursorGeometry(x, y, w, h);
});
```
And because it's invisible it wasn't obvious that it was wrong until you
enable `CLUTTER_PAINT=damage-region` and you can see its ghost at the wrong
offset and scale.
So now we `clutter_input_focus_set_cursor_location` using purely unscaled
stage coordinates. And `CLUTTER_PAINT=damage-region` shows that
gnome-shell's `_dummyCursor` is placed precisely over the visible cursor.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3399
and probably other IBus issues that arise when using framebuffer scaling.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1576>
`priv->cursor_rect` is stored in physical pixels, not local coordinates.
So unscale it before returning from `clutter_text_get_cursor_rect`, which
is explicitly documented as returning "actor-relative coordinates".
This went missed with fractional scaling support, and unnoticed as nobody
uses `clutter_text_get_cursor_rect` yet. But that will soon change.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1576>
Before now it was assumed that the only negative local coordinates would
be those introduced by `_clutter_actor_box_enlarge_for_effects`, and we
used the difference for `fbo_offset_x/y`. But that was misguided (of me)
because gnome-shell can give us paint volumes at negative coordinates too,
like when rendering `box-shadow` on the top or left edge of an actor.
The maximum extents of negative coordinates we might need to render are
in fact the (enlarged) left and top edges of the paint volume. So use
those as the FBO offset. This places the actor's local origin correctly
within the FBO and thus also ensures it's not over-clipped at the edges
of the FBO, which now line up with the enlarged extents of the paint
volume.
This fixes one third of
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1090
The other fixes required are !1053 and gnome-shell!1417.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1538>
Apparently it can happen that a timeline tries to pick a frame clock
from an actor that's on a stage, but the actor still doesn't find a
frame clock and returns NULL.
This probably is the case when starting a timeline right after attaching
an actor to a newly created stage, so before the first stage-update
cycle. In this case clutter_actor_update_stage_views() will not have run
and the stage-actor will have priv->stage_views set to NULL even though
there are stage views.
To prevent this from happening, use the complete list of stage views
maintained by the backend when picking a frame clock for the stage.
This doesn't fix any issue appearing on master, but is correct
nonetheless.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1631>
Instead of using native backend platform data specifically, store
this info in ClutterMotionEvent. This includes time in usec since
it's just used for motion events, in the future it could make sense
to make these general to all events again, but it could make sense
to make ClutterEvent structs private before.
In order to express that a motion event has relative motion info,
the CLUTTER_EVENT_FLAG_RELATIVE_MOTION event flag has been added
for it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1623>
We had code in both backends that sort of independently associated
sequences to slots. Make both transform slots to sequences the same
way, so they may share the implementation convert those back to slots.
This helper now lives in Clutter API.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1623>
We have this as platform-dependent data in the native backend, and
a bunch of fallback code done in place in the evcode users. Stop
making this platform-dependent data, and move it to the relevant
ClutterEvents.
The fallback code for the X11 backend case is about the same, but
now it is done directly by the X11 backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1623>
Making this an event is overly convoluted, accounting that we
emit the event, then convert it to a ClutterStage signal, then
its only consumer (a11y) sets the active ATK state.
Take the event out of the equation, unify activation/deactivation
of the stage in MetaStage, and use it from the X11 backend too.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1623>
It is not possible to express a blit operation using paint
nodes as of now. This is a requirement for GNOME Shell, e.g.,
to implement its blur effect.
Add a new ClutterBlitNode node that takes two framebuffers as
input, and blits the source framebuffer into the current one
according to added rectangles.
Because this paint node uses the rectangles in a different way
compared to all the other nodes, add an auxiliary method to
ensure all blit operations are valid.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1340>
ClutterLayerNode is the "offscreen framebuffer" node, that paints it's
child nodes in a separate framebuffer, and then copies that framebuffer
to the parent one.
It'll be useful to hand ClutterLayerNode which framebuffer and pipeline
to use, as this is a requirement for porting e.g. ClutterOffscreenEffect
and subclasses.
Add a new clutter_layer_node_new_to_framebuffer() API.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1340>
Some effects, such as ShellBlurEffect and ClutterOffscreenEffect, need
to make sure the actor is painted fully opaque. With ClutterActorNode,
however, that is currently not possible.
Add a new 'opacity' parameter to clutter_actor_node_new(). It follows
the opacity override heuristic, where -1 means disable, and anything
else is clamped to [0, 255].
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1340>
Introduce a new paint_node vfunc that, if implemented, allows
the effect to add nodes to a transient paint node that is
immediately painted. This is a transitional step until we
have fully delegated paint node rendering.
The most basic implementation of a ClutterEffect.paint_node
vfunc, and also the default implementation, is with an actor
node, as follows:
```
static void
foo_bar_paint_node (ClutterEffect *effect,
ClutterPaintNode *node,
ClutterPaintContext *paint_context,
ClutterEffectPaintFlags flags)
{
g_autoptr (ClutterPaintNode) actor_node = NULL;
actor_node = clutter_actor_node_new (effect->actor);
clutter_paint_node_add_child (node, actor_node);
}
```
This example gives the exact same behavior of simply calling
clutter_actor_continue_paint(). In the future, the paint node
itself will be a parameter of clutter_actor_continue_paint()
and we'll be able to simplify it event more.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1340>
ClutterEffectNode is a private ClutterPaintNode implementation
that does effectively nothing, but helps organizing the paint
node tree. It also helps debugging, since it can output the
effect class and name to the JSON debugging routines.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1340>
The idea of having a paint node tree is that we don't really need
to retrieve the framebuffer from ClutterPaintContext. For example,
ClutterLayerNode draws into an offscreen framebuffer; if any child
of a layer node needs to retrieve a framebuffer to draw, the layer
node's offscreen framebuffer should be used.
However, clutter_paint_node_get_framebuffer() goes straight to the
root node of the tree, skipping any potential paint nodes with a
custom framebuffer.
Modify clutter_paint_node_get_framebuffer() to walk up the paint
node tree until a node with a custom framebuffer appears. In many
cases, this will end up either in dummy or layer node's custom
framebuffer implementations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1340>
Fixes a compiler warning with -Wmaybe-uninitialized enabled:
../../../../Source/gnome/mutter/clutter/clutter/clutter-actor.c: In function ‘clutter_actor_paint’:
../../../../Source/gnome/mutter/clutter/clutter/clutter-actor.c:3808:50: warning: ‘result’ may be used uninitialized in this function [-Wmaybe-uninitialized]
3808 | else if (result == CLUTTER_CULL_RESULT_OUT && success)
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
Which might presumably happen in the unlikely case that there's no clip
frusta.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1624>
Instead of going through the event queue, stage handling code, and
back to the input device via a vmethod call, do this directly in the
MetaSeatImpl. This is not too different from X11, where everything
happens inside the backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
All that is left in the "public" struct is all state that ClutterStage
delegates on ClutterInputDevice. That should move somewhere else, but
not here, not now.
All private fields belong to construct-only properties, with only getter
API, and idempotent vmethods (except keyboard a11y, atm). This should
be enough to make ClutterInputDevice obviously thread safe, outside the
backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Depending on the backend, we want to integrate this object at different
levels. It will sit close to the MetaBackendX11/MetaSeatX11 in X11, but
it will be put deep down with MetaSeatImpl in the native backend, in a
separate thread.
Since we can't depend on a single object type, nor are able to track
ClutterSeat signals neatly, make this API something to be called
explicitly by backends.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
This will query a device state; position and modifiers.
Note that ClutterSeat subclasses don't implement the vmethod yet,
so calling clutter_seat_query_state() may crash ATM.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Testing points and rays against boxes is substantially cheaper - in
fact, almost trivial - compared to triangles. Check if the actor's
paint volume doesn't intersect with the current pick point / ray,
and skip recursing altogether in those cases.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1520>
The cached pick mode never actually cached anything, since it is
always, unconditionally reset when painting. Furthermore, next
commits will cull out actors during pick, which makes the pick
stack uncacheable.
Remove the cached pick mode.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1520>
Users of Debian arm64 (aarch64) report that on at least some GPUs
or screens, after time-based screen blanking has occurred, it is not
possible to unlock the screen. Bisection indicates that this regressed
in commit 209b1ba3, so presumably this is because a refresh rate of 0
is reported while the screen is blanked, leading to the frame clock
pausing forever.
Fixes: 209b1ba3 "clutter/frame-clock: Adapt refresh rate from to frame info"
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1536
Bug-Debian: https://bugs.debian.org/974172
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1601>
It's currently possible that some last_paint_volumes don't get updated
during a paint cycle, this can happen when a ClutterOffscreenEffect is
used: The offscreen effect might skip painting the content and the
children of an actor because it uses its own offscreened texture
instead. This means the offscreen effect doesn't call
clutter_actor_continue_paint(), and thus the the last_paint_volumes of
the children won't be updated.
Now one might think that isn't a problem, because as soon as a child
changes it's size or position, the offscreened texture would get
invalidated and clutter_actor_continue_paint() would get called. It's
not that easy though: Because the last_paint_volume includes all the
transformation matrices up to eye-coordinates, it has to be updated on
any changes to matrices, which includes position/transformation changes
to any actor up the hierarchy.
Now that's where get into problems with the offscreen effect: In case of
transformation changes to the offscreened actor or an actor up the
hierarchy, the offscreened texture won't get invalidated (that makes
sense, we can simply paint it transformed) and the last_paint_volumes
won't get updated even though they should.
This leaves us around with outdated last_paint_volumes where
last_paint_volume_valid is still set to TRUE. It can cause issues with
culling and clipped redraws.
So fix that by ensuring that all children that would get painted by
Clutter get their last_paint_volumes updated in case a ClutterEffect
decided not to call clutter_actor_continue_paint().
This ignores the case where a paint() vfunc override does the same and
doesn't call clutter_actor_paint() on children. Let's ignore this case
for now, there shouldn't be any implementation which does that and
ideally in a world that's painted solely by ClutterContent, we can get
rid of that vfunc in the future.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1591>
The first comment isn't really needed anymore since
the is_full_stage_redraw_queued() underneath is quite self-explaining.
Also rephrase the second comment a bit, including that
_clutter_paint_volume_get_stage_paint_box() does the aligning to the
pixel grid.
Finally, the last comment also looks out of date since we do that
rounding inside _clutter_paint_volume_get_stage_paint_box(), so remove
it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1511>
We currently pass actors a reference to their associated
ClutterStageQueueRedrawEntry when queueing a redraw. This "splitting" of
the ownership of the entry has introduced quite a few bugs in the past
and is hard to follow.
So give up the "splitting" of the ownership and exclusively handle those
entries inside ClutterStage. To still allow removing the entry when an
actor gets unrealized introduce clutter_stage_dequeue_actor_redraw()
similar to what we already have for relayouts.
To be able to efficiently find entries when actors queue redraws, make
pending_queue_redraws a GHashTable, which fits quite nicely and also
allows removing the QueueRedrawEntries actor pointer in favour of the
key of the hashtable.
Since the struct is now private to ClutterStage, we can also rename it
to QueueRedrawEntry.
While at it, also sneak in the removal of the leading underscore from
clutter_stage_queue_actor_redraw().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1511>
The "queue-redraw" signal is not used anywhere in Clutter and we now
also removed the vfunc implementation of the stage. So stop emitting it
and remove it, but keep the propagate_queue_redraw infrastructure to
make sure clones still get their redraws queued.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1511>
Since we now decoupled the "queue-redraw" signal from creating the stage
clip, we can move signal emission into
_clutter_actor_queue_redraw_full() and emit the signal right away when
queueing a redraw on an actor. With that we now no longer have to
accommodate for the stage pending_queue_redraws list changing while
iterating over it.
To ensure we don't emit the signal too often when multiple redraws are
queued on one actor, use the propagated_one_redraw flag to limit the
number of emissions to a single one for every update cycle.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1511>
Putting together the redraw clip of the stage never really fitted nicely
with the "queue-redraw" signal emission, it forces us to emit the
signals in a batch and we also use a weird trick to get the old paint
volume that's already on-screen into the final redraw clip (we call
_clutter_actor_propagate_queue_redraw() on the stage).
So start breaking up this association by making the stage explicitely
request the redraw clip from the actor and removing the
ClutterPaintVolume argument from _clutter_actor_finish_queue_redraw().
This is done by adding a private function
clutter_actor_get_redraw_clip() which returns our old (currently
visible) paint volume and the new paint volume.
This also allows removing the check whether a full stage redraw has been
queued in clutter_actor_real_queue_redraw() and we can now just stop the
signal emission if a propagation happened at least once.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1511>
The most common case for Clutter is 2D axis-aligned actors, which
maintain these properties even after projecting to eye coordinates.
In those cases, we can use a simpler hit test by checking against
boxes.
Not only this is simpler, but this maintains an important aspect
of picking that is a requirement for Clutter: watertightness. Even
though the triangles checks do work on x86_64, they do not guarantee
watertightness. This breaks tests on ARM.
Use graphene_box_t to hit-test axis-aligned 2D actors.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1599>
clutter_actor_paint() implements a clear preference for custom clips
over clip_to_allocation: If a custom clip is set, clip_to_allocation is
ignored.
Since the paint volume reflects what Clutter is going to paint, we
should handle it the same when putting together our paint volume: So
first handle custom clips, and if one is set, use that. Then handle
clip_to_allocation, and if that's set, use that. And finally, if both
aren't set, union our allocation with the children paint volumes to get
the building volume.
clutter_actor_paint() also doesn't check whether the custom clip is
empty: If that's the case, it will simply not paint anything. Given that
that's allowed by clutter_actor_paint(), the paint volume should also
follow here and return an empty paint volume in case the custom clip is
empty.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1592>
When a custom clip is set for an actor, this actor is not going to allow
any painting outside that clip. That includes the children, which may
also not paint outside that clip.
Now in case clip_to_allocation is set to TRUE, we already already do the
right thing and simply use the allocation as our paint volume, ignoring
the volumes of our children. The same should be done for the custom
clip, so also stop the process of building the paint volume once we see
that a custom clip is set and simply use that clip.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1592>
When using CLUTTER_DEBUG_PAINT_DAMAGE_REGION, the blue swap region is
always a superset of the red redraw region. So painting both in full (since
the previous commit) just meant the red region was overdrawn and came out
purple. That doesn't provide enough visual contrast, changes the user
experience unexpectedly and reduces performance.
So just subtract the redraw region from the swap region. This way the
red redraw region is always red, not purple.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1571>
Previously when CLUTTER_DEBUG_PAINT_DAMAGE_REGION was set, that would lead
to has_buffer_age==FALSE, which would lead to use_clipped_redraw==FALSE
which would mean swap_region was always empty. And so the blue region of
CLUTTER_DEBUG_PAINT_DAMAGE_REGION was always empty, *and* fb_clip_region
was always the full view rectangle which is not useful for debugging.
Now when CLUTTER_DEBUG_PAINT_DAMAGE_REGION is set, we don't let that
affect use_clipped_redraw, which means fb_clip_region is calculated
realistically.
But that's not enough. Calculating fb_clip_region properly with
CLUTTER_DEBUG_PAINT_DAMAGE_REGION would still lead to colouring artefacts
left on screen from previous frames that don't apply to the current frame.
So to fix that we also paint_stage for the whole screen every time when
using CLUTTER_DEBUG_PAINT_DAMAGE_REGION.
So now you will only ever see red and blue shading that's applicable to
the current frame, and no artefacts from the previous frames.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1535
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1571>
It was being painted without scaling and offsetting so would only look
right at scale 1.0 and only on the view with origin (0,0). Now we include
the framebuffer scale and view origin it will be painted in the correct
location.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1571>
As explained in https://gitlab.gnome.org/GNOME/mutter/-/issues/1494,
with commit 29caa5bea5 we stopped queueing
a relayout for the parent of the removed actor in
clutter_actor_remove_child_internal(). This relayout was, as opposed to
the relayout in clutter_actor_real_hide()/clutter_actor_real_unmap(),
queued unconditionally without looking at the parents NO_LAYOUT flag.
Now while that relayout in clutter_actor_remove_child_internal() would
do unnecessary work if the parent had the NO_LAYOUT flag set, it did
also queue a redraw of the parent, which is necessary in any case.
So by removing that relayout in clutter_actor_remove_child_internal(),
we stopped queueing redraws for NO_LAYOUT parents when a child gets
removed from the scenegraph. This caused bugs where the texture of the
child would be left visible on the screen even though the child got
destroyed.
To fix this, make sure again that we always queue a redraw on the parent
when unmapping a child.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1494
The redraw_pending boolean is used to schedule the first stage update
after starting Clutter. This flag is superfluous because we have the
pending_finish_queue_redraws flag which does the same.
While at it, also remove the redraw_count debug variable, since there
should be better ways to count the number of queued redraws nowadays,
for example Sysprof marks.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1527
Queueing a redraw with a clip is easy enough and this function is
private anyway, so remove it and call _clutter_actor_queue_redraw_full()
instead in the one function using it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1527
ClutterRedrawFlags are a way to give Clutter additional context
about what it needs to redraw. There currently is only one flag defined,
CLUTTER_REDRAW_CLIPPED_TO_ALLOCATION, this flag would clip the redraw to
the actors current allocation.
Since ClutterActor also provides the clip_to_allocation property (which
affects the paint volume of the actor instead of only one redraw), the
additional CLIPPED_TO_ALLOCATION flag seems unnecessary. It's also only
defined to be used privately in Clutter, which it never is, so let's
remove it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1527
Turns out the g_signal_has_handler_pending() call in
update_stage_views() is actually more expensive than comparing the
sorted list (which is usually very short), so remove that and simply
always emit the signal.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1524
This commit introduces a few important changes in order to
acommodate graphene_ray_t. Most of them are positive changes,
so don't panic :)
The first very visible change is that neither the actor box
nor the clip rectangles are projected before being pushed.
This required changing the parameters of the related functions
at both ClutterPickContext, and ClutterPickStack, to receive
boxes instead of vertices. These rectangles are projected on
demand now, so in the best case (first actor picked) only
one projection happens; and in the worst case, it projects
as much as it does now.
The second important change is that there are no more checks
for axis-alignment anymore. That's because picking now happens
in 3D space, using triangles.
Talking about triangles in 3D space, this is what is used now
for picking. We break down each actor rectangle in 2 triangles,
and check if the projected pick point is inside any one of them,
of if the ray intersects any one of them. The same check happens
for the clip rectangles.
Checking the projected pick point is both an optimization for the
2D case, and a workaround to graphene_ray_t problems with float
precision, which is specially visible on edges such as the top
bar.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1509
ClutterPickStack is a new boxed type that stores the vertices
and clip rectangles. It is meant to be a byproduct of picking,
and takes over most of what ClutterStage currently does.
It introduces a 'seal' system, inspired by MetaKmsUpdate. After
the pick operation is done, and the rectangles are collected,
the pick stack is sealed, and is not allowed to be externally
modified anymore. Internally, it still can invalidate pick
records when an actor is destroyed.
For now, it handles both the clip rectangles, and the matrix
stack, separatedly. Future commits will rearrange this.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1509
The "paint" signal of ClutterActor has been a pain for everyone involved
long enough now, turns out we actually use it nowhere except tests
anymore (which has been handled in the last commits), so get rid of it
for good before anyone starts using it again.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1522
This is a bit scattered around, with the setter/getter in Clutter, and
it only being only directly honored in Wayland (it goes straight through
device properties in X11).
Make this private native API, and out of public ClutterInputDevice API.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1486
Since commit eb9cd3857d we initialize the allocation of ClutterActors to
an UNINITIALIZED ClutterActorBox. We do that to ensure the actor even
emits notify::allocation in case it got a new valid allocation of
0,0,0,0.
Now there's still the case where an actor gets removed from the
scenegraph and added again to a different parent, in this case we still
don't emit notify::allocation right now in case the new allocation
equals the old one. There's two good reasons to do so though:
1) To Clutter, there's no difference between a newly created actor and
an actor which got removed from the scenegraph, it's not consistent to
always notify the allocation property in the former situation, but not
always notify it in the latter situation.
2) When an allocation changes, Clutter notifies the subtree of that
actor about an absolute geometry change (see the call to
transform_changed() in clutter_actor_set_allocation_internal()). Now
when an actor gets reparented, obviously the absolute geometry might
change, so to make sure transform_changed() is always called in that
case we need to make sure an allocation change happens.
So simply reset the allocation property of the actor to an UNINITIALIZED
ClutterActorBox as soon as it gets unrealized.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1498
We introduced the absolute_origin_changed flag when preparing for the
removal of ClutterAllocationFlags in commit dc8e5c7f8b. Turns out in the
mean-time commit df4eeff6f2 happened, which renders the whole
absolute_origin_changed flag moot.
That's because we now notify the whole subtree about the absolute origin
change by calling transform_changed() when the allocation of an actor
changes. transform_changed() traverses the subtree and calls
absolute_geometry_changed() on every actor immediately, which renders
the whole propagation of the absolute_origin_changed flag obsolete.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1498
Since we now moved the queuing of relayouts into the mapping and
unmapping functions, we no longer need to do it when adding or removing
a child, that's because removing a child always unmaps the child, and
adding it to a stage (if it's visible) will map it.
So remove those calls to queue_relayout() since they're no longer
needed.
With the above we no longer queue a relayout in
clutter_actor_add_child_internal(), that means there's one place where
we need to explicitely queue relayouts now: That's when using the
set_child_at_index/above/below() APIs, those are special because they
avoid unmapping and mapping of actors and would now no longer get a
relayout.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1366
In theory there's no big difference between only handling mapped actors
vs only handling visible actors in clutter_actor_allocate(): The
function is called recursively starting with an actor that is attached
to a stage, so it should only be called on mapped actors anyway.
The behavior of skipping hidden actors was introduced as an optimization
with commit 0eab73dc. Since the last commit, we handle
enable_paint_unmapped a bit better and don't do unnecessary work when
mapping or unmapping, so we can now be a bit stricter enforcing our
invariants and only allow mapped actors in clutter_actor_allocate().
We need to exclude toplevel actors from this check since the stage has a
very different mapped state than normal actors, depending on the
mappedness of the x11 window. Also we need to make an exception for
clones (of course...): Those need their source actor to have an
allocation, which means they might try to force-allocate it, and in that
case we shouldn't bail out of clutter_actor_allocate().
Also moving the clutter_actor_queue_relayout() call from
clutter_actor_real_show() to clutter_actor_real_map() seems to fix a bug
where we don't queue redraws/relayouts on children when a parent gets
shown.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2973https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1366
We currently support only one case where an actor can get mapped or
unmapped during painting, that is using
_clutter_actor_enable_paint_unmapped() (although we could arguably do a
better job explicitely forbidding it in other cases). This function is
called when painting ClutterClone or MetaWindowActors during
screensharing. It temporarily (fake) realizes and maps the actor and all
its children so it can get painted.
Now a problem will appear when we'll start coupling layout and the
mapped state of actors more closely with the next commit: Since
enable_paint_unmapped() is meant to be enabled and disabled during every
clone paint, we also notify the "mapped" property twice on every clone
paint. That means with the next commit we would queue a relayout for the
source actor on every clone paint.
To avoid this unnecessary work, check whether we're being painted while
unmapped using the new unmapped_paint_branch_counter. Then avoid queuing
relayouts or invalidating paint volumes in that case.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1366
Add new private API to ClutterActor, returning TRUE in case the actor is
being painted while unmapped. This is useful for implementations of the
paint() vfunc or for signal handlers of the "notify::mapped" signal.
Use this API in CallyActor to properly detect "notify::mapped" emissions
while painting unmapped, this fixes detecting the case where
painting-unmapped is used for screencasting.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1366
Just like the existing in_cloned_branch counter, add a property which
tracks whether the actor is part of a subtree that's being painted while
unmapped. This is going to be useful for a few things, for example
changing the clutter_actor_is_in_clone_paint() API to use
enable_paint_unmapped instead of in_clone_paint.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1366
clutter_actor_queue_relayout() detects whether a parent has the
NO_LAYOUT flag set by itself and then queues a shallow relayout for us.
There's no need to duplicate that logic when showing actors, so simply
call clutter_actor_queue_relayout() and let that handle it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1366
Apparently clutter_paint_volume_union() has problems building the union
of two paint volumes in eye coordinates, that's probably because of the
negative coordinates that come into play there.
Circumvent that by making even more use of Graphene and letting it take
care of computing the union. We do that by creating two graphene_box_t's
from the axis-aligned paint volumes and intersecting those boxes, then
setting our vertices to the new min and max points of the resulting box.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1507
Add a helper function to determine if a seat has a (physical)
touchscreen associated with it.
Currently src/backends/meta-backend.c has a private version of this
(check_has_physical_touchscreen) and further patches in this patch-set
need the same functionality. So add a generic helper for this to
avoid code duplication.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
_cogl_util_get_eye_planes_for_screen_poly() is quite a complicated beast. Ever
since Clutter became a compositor toolkit, and specially after we switched to
graphene_frustum_t on paint volumes, we can brutally simplify this function.
The new code assumes camera is at (0, 0, 0) at world coordinates (i.e. before
applying the projection). We also consider that the redraw clip are at stage
coordinates. That means that converting the clip rectangle to world rectangle
is simply a matter of projecting the corresponding vertices using the "view"
matrix. Furthermore, we only need to project the top-left, and bottom-right
vertices, since top-right and bottom-left can be derived from those two.
The frustum setup still uses triplets of vertices to setup the planes, except
now the first vertex is always the camera (hardcoded to 0, 0, 0), and the other
two vertices are the projected clip rectangle vertices.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
The redraw clip region may contain multiple clip rectangles. We currently
only use the extents of this region, but having multiple frusta for each
rectangle is a better alternative, and will allow us to remove the extra
projection we currently do.
Make the clip frustum an array, with multiple frusta.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
The clip planes / frustum are contextual to painting. In the past, for
the lack of a better place, it was added to ClutterStage, but now we
have an appropriate home for such data: ClutterPaintContext.
Move the frustum to the paint context.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
While refactoring the clipping planes / frustum code, it became more and
more evident that we do not need to update them while picking. Picking
nowadays goes through a completely different code path, that does not
rely on paint volume culling.
While it might be interesting to eventually also cull out based on paint
volumes, it certainly won't go through the painting code anymore.
Remove setting up the view when picking, and rename functions appropriatedly.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
Culling paint volumes don't give this level of detail anymore, and in
fact knowing whether it was partially or fully in was only being used
in a debug path. For the purposes of culling, it doesn't matter if a
given actor is partially or completely inside the frustum; either way,
it must be painted.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
Instead of 4 planes, use a graphene_frustum_t to store the clipping
planes.
The cautious reviewer might noticed that we are now setting up 6
planes: the 4 planes we were doing before, plus 2 extra planes in
the Z axis. These extra planes simulate an "infinite" Z far, and
an "on-camera" Z near.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
ClutterStage defines the 8 vertices of a frustum:
4 ----------------------------- 5
| \ / |
| \ / |
| 0 --------------------- 1 |
| | | |
| | | |
| 3 --------------------- 2 |
| / \ |
| / \ |
7 ----------------------------- 6
Then, it uses triplets of vertices to create each clipping plane.
It only sets up 4 planes (it doesn't clip based on depth), defined
by the following vertices:
* 0 - 4 - 5
* 1 - 5 - 6
* 2 - 6 - 7
* 0 - 7 - 4
The first 3 triplets are selected using the for-loop. However, the
last triplet is different, and is done out of the loop. It could
have been made simpler by using the "3 - 7 - 4" triplet.
Simplify the current code by using the suggested triplet, calculated
inside the for-loop.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
Instead of our own implementation that upscales, then downscales back,
use graphene_matrix_inverse() directly. This is possible after switching
to a z-near value that doesn't have problems with float precision.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
Picking is specially sensitive for float precision, and tests can
easily fail when something changes, even if ever so slightly. A
simple way to workaround this is by adjusting the projected points
using the same procedure described at 67cc60cbda.
Round projected points for picking to 256ths.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
A first step towards abandoning the CoglObject type system: convert
CoglFramebuffer, CoglOffscreen and CoglOnscreen into GObjects.
CoglFramebuffer is turned into an abstract GObject, while the two others
are currently final. The "winsys" and "platform" are still sprinkled
'void *' in the the non-abstract type instances however.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1496
The timestamp sent with _NET_WM_FRAME_DRAWN should be in "high
resolution X server timestamps", meaning they should have the same scope
as the built in X11 32 bit unsigned integer timestamps, i.e. overflow at
the same time.
This was not done correctly when mutter had determined the X server used
the monotonic clock, where it'd just forward the monotonic clock,
confusing any client using _NET_WM_FRAME_DRAWN and friends.
Fix this by 1) splitting the timestamp conversiot into an X11 case and a
display server case, where the display server case simply clamps the
monotonic clock, as it is assumed Xwayland is always usign the monotonic
clock, and 2) if we're a X11 compositing manager, if the X server is
using the monotonic clock, apply the same semantics as the display
server case and always just clamp, or if not, calculate the offset every
10 seconds, and offset the monotonic clock timestamp with the calculated
X server timestamp offset.
This fixes an issue that would occur if mutter (or rather GNOME Shell)
would have been started before a X11 timestamp overflow, after the
overflow happened. In this case, GTK3 clients would get unclamped
timestamps, and get very confused, resulting in frames queued several
weeks into the future.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1494
Keeping track of the projected position is costly, and adds quite some complexity
to ClutterOffscreenEffect.pre_paint(). As far as research goes, there's not a
single consumer of this function that uses the position for anything - only size
is used.
Remove clutter_offscreen_effect_get_target_rect(), and drop the annoying position
field from ClutterOffscreenEffect as well. This allows us to stop projecting the
position on pre-paint, and simplify things.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1474
ClutterPipelineNode will be used by GNOME Shell in the future.
Fortunately for us, CoglPipeline is already usable from GJS,
so we don't need to skip the constructor for the pipeline node.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1474
Move unreffing the framebuffer to ClutterOffscreenEffect.pre_paint().
This will allow us to properly chain up ClutterOffscreenEffect.paint()
and not reimplement exactly what ClutterEffect does by default.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1474
In this case, since we are building the entire matrix by ourselves,
reverse the order of operations (translate + scale → scale + translate)
and build it using graphene-specific APIs.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
This is another instance of graphene reversing the order of operations (see
the commit notes of how ClutterActor was ported.) The tl;dr; here is that,
in the CoglMatrix past, we used to do:
(actor transforms) → scale
and now, it's the other way round:
scale → (actor transforms)
due to changing from right-handed multiplications (CoglMatrix) to left-handed
ones (graphene_matrix_t).
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
ClutterActor is a particularly heavy user of matrices, and
switching to graphene_matrix_* APIs means we had to change
the order of operations due to left-hand vs right-hand
differences.
When applying the actor transform, there are 2 main branches
that can be followed: the default transforms, and when a
custom transform is set.
To facilitate review, here's the table that I've made to
guide myself:
+--------------- Case 1: Default Transforms --------------+
| CoglMatrix | graphene_matrix_t |
+----------------------------+----------------------------+
| multiply (child transform) | translate (-pivot) |
| translate (allocation)¹ | rotate_x (angle) |
| translate (pivot)¹ | rotate_y (angle) |
| translate (translation)¹ | rotate_z (angle) |
| scale (sx, sy, sz) | scale (sx, sy, sz) |
| rotate_z (angle) | translate (translation)¹ |
| rotate_y (angle) | translate (pivot)¹ |
| rotate_x (angle) | translate (allocation)¹ |
| translate (-pivot) | multiply (child transform) |
+----------------------------+----------------------------+
¹ - these 3 translations are simplified as a single call
to translate(allocation + pivot + translation)
+---------------- Case 2: Custom Transform ---------------+
| CoglMatrix | graphene_matrix_t |
+----------------------------+----------------------------+
| multiply (child transform) | translate (-pivot) |
| translate (allocation)² | multiply (transform) |
| translate (pivot)² | translate (pivot)² |
| multiply (transform) | translate (allocation)² |
| translate (-pivot) | multiply (child transform) |
+----------------------------+----------------------------+
² - likewise, these 2 translations are simplified as a
single call to translate(allocation + pivot)
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
CoglMatrix already is a typedef to graphene_matrix_t. This commit
simply drops the CoglMatrix type, and align parameters. There is
no functional change here, it's simply a find-and-replace commit.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
Ideally, we would use Graphene to do that, however as of now Graphene
lacks these APIs so we still need these helpers. Since we're preparing
to get rid of CoglMatrix, move them to a separate file, and rename them
with the 'cogl_graphene' prefix.
Since I'm already touching the world with this change, I'm also renaming
cogl_matrix_transform_point() to cogl_graphene_matrix_project_point(),
as per XXX comment, to make it consistent with the transform/projection
semantics in place.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
Given that CoglMatrix is simply a typedef to graphene_matrix_t, we can
remove all the GType machinery and reuse Graphene's.
Also remove the clutter-cogl helper, and cogl_matrix_to_graphene_matrix()
which is now unused.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
It turns it to be quite easy to inverse the transform, and doing that
on ClutterActor level means we can actually think about removing
CoglMatrix entirely and using graphene_matrix_t everywhere.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
CoglMatrix doesn't have a 1:1 mapping of graphene functions, and
sometimes it's just not worth adding wrappers over it. It is easier
to expose the internal graphene_matrix_t and let callers use it
directly.
Add new cogl_matrix_get_graphene_matrix() helper function, and
simplify Clutter's matrix progress function.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
Rename cogl_matrix_get_array() to cogl_matrix_to_float(), and
make it copy the floats to an out argument instead of returning
a pointer to the casted CoglMatrix struct.
The naming change is specifically made to match graphene's,
and ease the transition.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
Graphene provides skewing as part of graphene_matrix_t API, and it'll
be easier for the transition to just expose similar API surfaces.
Move the matrix skew methods to CoglMatrix.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
Even when a direct client buffer has a compatible format, stride and
modifier for direct scanout, drmModePageFlip() may still fail sometimes.
From testing, it has been observed that it may seemingly randomly fail
with ENOSPC, where all subsequent attempts later on the same CRTC
failing with EBUSY.
Handle this by falling back to flipping after having composited a full
frame again.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1410
We already correctly set the font-dpi based on user settings in
MetaSettings at each user change and as part of backend initialization,
so there's no point to set it also during x11 backend post-parsing and
using X11 values, as this may happen at later point and lead to a wrong
clutter font DPI value.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1444
It'll allow subclasses to get notified of the before-paint
signal without having to connect to it. This will allow
MetaStage to have proper watches being fired there without
the cost of the signal handling machinery.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1421
Just because X11/XI uses a particular terminology doesn't mean we
have to use the same terms in our own API. The replacement terms
are in line with gtk@1c856a208, which seems a better precedent
for consistency.
Follow-up to commit 17417a82a5.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1425
These are not given directly to the input focus anymore, instead
queued up as events. This way, all actions triggered by the input
method (commit and preedit buffer ones, but also synthesized key
events) queue up the same way, and are thus processed in the exact
same order than they are given to us.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1286
The clutter_input_focus_filter_key_event() function has been made
a more generic filter_event(). Besides its old role about letting
key events go through the IM, it will also process the IM events
that are possibly injected as a result.
Users have been updated to these changes.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1286
Previously we only culled actors that didn't intersect the bounding box
of the redraw clip. Now we also cull those whose paint volume bounds don't
intersect the arbitrary shape of the redraw clip.
This was inspired by the activities overview where idle windows and
workspace previews were being needlessly repainted. In that particular
case this yields more than 10% reduction in render time. But it probably
helps in other situations too.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1359
Clutter device events are special events coming from the backend when an
input device is added or removed.
When such events are processed, we should make the seat to handle them by
calling vfunc that can be implemented by each backend and eventually
emitting the appropriate signal.
If a device is removed, we can also safely dispose it, as it can be
considered stale at this point.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1371
Add clutter device added and removed events to allow processing of them as
it happens in the backends, queuing them and performing actions in order.
This allows not to loose any event that is performed just before removing or
disabling a device, and still process the events in order in the event
queue.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1371
This was from the old clutter-as-application-library days, where it had
to try find a suitable backend. Now we already have a backend selected
(MetaBackend), and the clutter backend is already predecided depending
on that, so we don't need the code that auto detects an appropriate one
anymore.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1364
There is no reason to use Xsettings for the X11 backend, as it comes
from the GSetting store anyway, so move the font setting reading to
ClutterSettings and read directly from GSettings.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1364
The delete event was used for signalling the close button was clicked on
clutter windows. Being a compositor we should never see these, unless
we're running nested. Remove the plumbing of the DELETE event and just
directly call meta_quit() when we see it, if we're running nested.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1364
We checked if we were using the usig the X11 backend to decide when to
deal with a11y event posting - in order to make the clutter code less
windowing system dependent, make this check a check whether we're a
display server or not, in contrast to a window/compositing manager
client. This is made into a vfunc ot ClutterBackendClass, implemented by
MetaClutterBackendNative and MetaClutterBackendX11.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1364
When we pick the frame clock given the associated actor, that frame
clock in fact comes from a picked actor. In order to not end up with
stale frame clocks, which may happen on e.g. hotplugs, monitor layout
changes, or non-optimal frame clocks, which may happen when the parent
used for picking the clock moves to another view, lets listen to
'stage-views-changed' on the actor used for picking the clock too.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1327https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1404
Let's not expose that outside of mutter quite yet; it's not used in
gnome-shell, and to avoid future breakage if it starts to be used, lets
move it to clutter-mutter.h so only mutter and clutter itself can use
it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1404
This aims to make sure a view and its resources are destroyed when it
should. Using references might keep certain components (e.g frame clock)
alive for too long.
We currently don't take any long lived references to the stage view
anywhere, so this doesn't matter in practice, but this may change, and
will be used by a to be added test case.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1404
Always force-track the cursor position (so that the X11 backend can keep
it up to date), and if the cursor wasn't part of the sampled
framebuffer when reading pixels into CPU memory, draw it in an extra
pass using cairo after the fact. The cairo based cursor painting only
happens on the X11 backend, as we otherwise inhibit the hw cursor.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1391
On X11 we won't always receive cursor positions, as some other client
might have grabbed the pointer (e.g. for implementing a popup menu). To
make screen casting show a somewhat correct cursor position, we need to
actively poll the X server about the current cursor position.
We only really want to do this when screen casting or taking a
screenshot, so add an API that forces the cursor tracker to track the
cursor position.
On the native backend this is a no-op as we by default always track the
cursor position anyway.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1391
The clutter_actor_get_transformed_position returns the position of the
top left point of the actor, with the actor transformations. That means
that if the actor is rotated 180º it'll return the "screen" position top
right.
Using this to calculate if the actor is in the screen is causing
problems when it's transformted.
This patch adds a new function clutter_actor_get_transformed_extents,
that will return the transformed actor bounding rect.
This new function is used on the update_stage_views so the actor will
get updated. this way rotated actors will be updated if they are on the
screen.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1386
Make clutter_actor_allocate_preferred_size() convenient to use from
layout managers by not "automatically" honouring the fixed position of
the actor, but instead allowing to pass a position to allocate the
actor at.
This way we can move the handling of fixed positions to
ClutterFixedLayout, the layout manager which is responsible for
allocating actors using fixed positions.
This also makes clutter_actor_allocate_preferred_size() more similar to
clutter_actor_allocate_available_size().
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1310
It's currently a bit hard to get the fixed position of an actor. It can
be either done by using g_object_get() with the "fixed-x"/"fixed-y"
properties or by calling clutter_actor_get_position().
Calling clutter_actor_get_position() can return the fixed position, but
it might also return the allocated position if the allocation is valid.
The latter is not the best behavior when querying the fixed position
during an allocation, so introduce a new function
clutter_actor_get_fixed_position() which always gets the fixed position
and returns FALSE in case no fixed position is set.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1310
With the introduction of the shallow relayout mechanism another small
but severe regression sneaked into our layout machinery: We might
allocate an actor twice during the same allocation cycle, with one
allocation happening using the wrong parent.
This issue happens when reparenting an actor from a NO_LAYOUT parent to
a non-NO_LAYOUT parent, in particular it triggered a bug in gnome-shell
when DND reparents a child from the NO_LAYOUT uiGroup to the overviews
Workspace actor after a drag ended. The reason the issue happens is the
following chain of events:
1. child of a NO_LAYOUT parent queues a relayout, this child is added to
the priv->pending_relayouts list maintained by ClutterStage
2. child is reparented to a different parent which doesn't have the
NO_LAYOUT flag set, another relayout is queued, this time a different
actor is added to the priv->pending_relayouts list
3. the relayout happens and we go through the pending_relayouts list
backwards, that means the correct relayout queued during 2. happens
first, then the old one happens and we simply call
clutter_actor_allocate_preferred_size() on the actor, that allocation
overrides the other, correct one.
So fix that issue by adding a method to ClutterStage which removes
actors from the pending_relayouts list again and call this method as
soon as an actor with a NO_LAYOUT parent is detached from the stage.
With that in place, we can also remove the check whether an actor is
still on stage while looping through pending_relayouts. In case
something else is going wrong and the actor is not on stage,
clutter_actor_allocate() will warn anyway.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1356
When picking which frame clock to use, we traverse up in the actor
hierarchy until a suitable frame clock is found. ClutterTimeline
also listens to the 'stage-views-changed' to make sure it's always
attached to the correct frame clock.
However, there is one special situation where neither of them would
work: when the stage doesn't have a frame clock yet, and the actor
of the timeline is outside any stage view. When that happens, the
returned frame clock is NULL, and 'stage-views-changed' is never
emitted by the actor.
Monitor the stage for stage view changes when the frame clock is
NULL.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
An actor may be placed without being on any current stage view; in this
case, to get the ball rolling, walk up the actor tree to find the first
actor where a frame clock can be picked from.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
The frame clock owner should be able to explicitly destroy (i.e. make
defunct) a frame clock, e.g. when a stage view is destructed. This is so
that other objects can keep reference to its without it being left
around even after stopped being usable.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
Replace the default master clock with multiple frame clocks, each
driving its own stage view. As each stage view represents one CRTC, this
means we draw each CRTC with its own designated frame clock,
disconnected from all the others.
For example this means we when using the native backend will never need
to wait for one monitor to vsync before painting another, so e.g. having
a 144 Hz monitor next to a 60 Hz monitor, things including both Wayland
and X11 applications and shell UI will be able to render at the
corresponding monitor refresh rate.
This also changes a warning about missed frames when sending
_NETWM_FRAME_TIMINGS messages to a debug log entry, as it's expected
that we'll start missing frames e.g. when a X11 window (via Xwayland) is
exclusively within a stage view that was not painted, while another one
was, still increasing the global frame clock.
Addititonally, this also requires the X11 window actor to schedule
timeouts for _NET_WM_FRAME_DRAWN/_NET_WM_FRAME_TIMINGS event emitting,
if the actor wasn't on any stage views, as now we'll only get the frame
callbacks on actors when they actually were painted, while in the past,
we'd invoke that vfunc when anything was painted.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/903
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
We'd emit multiple "presented" signals per frame, one for "sync" and one
for "completion". Only the latter were ever used, and removing the
differentiation eases the avoidance of cogl onscreen framebuffer frame
callback details leaking into clutter.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
Right now the stage only had a signal called 'after-paint' which was not
tied to painting but updating. Change this to offer 4 signals, for the 4
different stages:
* before-update - emitted in the beginning before the actual stage
updating
* before-paint - emitted before painting if there will be any stage
painting
* after-paint - emitted after painting if there was any stage painting
* after-update - emitted as a last step of updating, no matter whether
there were any painting or not
Currently there were only one listener, that should only really have
been called if there was any painting, so no changes to listeners are
needed.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
The mutexes was used by ClutterTexture's async upload and to match GDK's
mutexes on X11. GDK's X11 connection does not share anything with
Clutter's, we don't have the Gdk Clutter backend left, and we have
already removed ClutterTexture, so lets remove these mutexes as well.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
A frame clock dispatch doesn't necessarily result in a frame drawn,
meaning we'll end up in the idle state. However, it may be the case that
something still requires another frame, and will in that case have
requested one to be scheduled. In order to not dead lock, try to
reschedule directly if requested after dispatching, if we ended up in
the idle state.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
The frame clock wouldn't be useable yet, but none the less, add API to
get the frame clock best suited for driving the actor. Currently this
translates to the fastest one, but that might change.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
The frame clock is meant to eventually drive the painting of the view,
in contrast to the master frame clock painting every view on the stage.
Right now it's a useless place holder.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
The native backend had a plain counter, and the X11 backend used the
CoglOnscreen of the screen; change it into a plain counter in
ClutterStageCogl. This also moves the global frame count setting to the
frame info constuctor.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
We currently have mutter set a global frame counter on the frame info in
the native backend, but in order to do this from clutter, change the
frame info construction from being implicitly done so when swapping
buffers to having the caller create the frame info and passing that to
the swap buffers call.
While this commit doesn't introduce any other changes than the API, the
intention is later to have the caller be able to pass it's own state
(e.g. the global frame count) along with the frame info.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
We had time unit conversion helpers (e.g. us2ms(), ns2us(), etc) in
multiple places. Clean that up by moving them all to a common file. That
file is clutter-private.h, as it's accessible by both from clutter/ and
src/.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
Currently unused, but it's intention is to use as a initial refresh rate
for a with the stage view associated frame clock. It defaults to 60 Hz
if nothing sets it, but the native backend sets it to the associated
CRTCs current mode's refresh rate.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
Without an associated actor, or explicit frame clock set, in the future
a timeline will not know how to progress, as there will be no singe
frame clock to assume is the main one. Thus, deprecate the construction
of timelines without either an actor or frame clock set.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
The association is inactive, as in it doesn't do anything yet, but it
will later be used to determine what frame clock should be driving the
timeline by looking at what stage view the actor is currently on.
This also adapts sub types (ClutterPropertyTransition) to have
constuctors that takes an actor just as the new ClutterTimeline
constructor.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
This is so something outside of clutter-stage.c (i.e.
clutter-stage-view.c) can eventually do various things
_clutter_stage_do_update() does now while not redrawing the whole stage.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
Devices are updated (repicked) as part of the stage update phase, as
their stacking, position and transform might have changed since since
the last update.
The redraw clip was used to avoid unnecessary updating of devices, if
the device in question had it's position outside of the redraw clip. If
the device coordinate was outside of the redraw clip, what was
underneith the device couldn't have changed.
What it failed to do, however, was to update devices if a relayout had
happened in the same update, as it checked the state whether a layout
had happened before attempting to do a relayout, effectively delaying
the device updating to the next update.
This commit changes the behavior to always update the device given the
complete redraw clip caused by all possible relayouts of the same update
as the device update happens in.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
We'd check if there was any queued redraw on the stage, but this is
inappropriate for two reasons:
1) A monitor and area screen cast source only cares about damage on a
subset of the stage.
2) The global pending-redraw is going away when paint scheduling will be
more view centric.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
This will allow anyone to finish any queued redraws making their
corresponding damage end up being posted to the stage views. This will
allow units to check whether, so far, any updates are queued on a
particular stage view.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
Add API to add and remove ClutterTimeline objects to the frame clock.
Just as the legacy master clock, having a timeline added to the frame
clock causes the frame clock to continuously reschedule updates until
the timeline is removed.
ClutterTimeline is adapted to be able to be driven by a
ClutterFrameClock. This is done by adding a 'frame-clock' property, and
if set, the timeline will add and remove itself to the frame clock
instead of the master clock.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
The timestamp comes from the GSource, meaning it's a more accurate
representation of when the frame started to be dispatched compared to
getting the current time in any callback.
Currently unused.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
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
