Delayed clutter timelines might be removed while they are still in the
process of being executed, but if they are not playing yet their delay
timeout won't be stopped, causing them to be executed anyway, leading to a
potential crash.
In fact if something else keeps a reference on the timelines (i.e. gjs), the
dispose vfunc delay cancellation won't take effect, causing the timelines to
be started and added to the master clock.
To avoid this, expose clutter_timeline_cancel_delay() function and call it
if a timeline is not playing but has a delay set.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/815https://gitlab.gnome.org/GNOME/mutter/merge_requests/805
If a timeline is delayed and we request to stop or pause it, we are emitting
the "::paused" signal on it, however this has never been started, and so
nothing has really be paused.
So, just try to cancel the delay on pause and return if not playing.
No code in mutter or gnome-shell is affected by this, so it is safe to
change.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/805
Clutter stage used to compute the initial projection using a fixed z
translation which wasn't matching the one we computed in
calculate_z_translation().
This caused to have a wrong initial projection on startup which was then
correctly recomputed only at the first paint.
However, since this calculation doesn't depend on view, but only on viewport
size, perspective's fovy and z_near we can safely do this at startup and
only when any of those parameters change.
Then we can move the computation out _clutter_stage_maybe_setup_viewport()
since the cogl framebuffer viewport sizes aren't affecting this.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1639https://gitlab.gnome.org/GNOME/mutter/merge_requests/803
When suspending, the devices are removed and the virtual device
associated with the corresponding core pointer is disposed.
Add the pointer accessibility virtual device to the core pointer
on resume to restore pointer accessibility on resume if enabled.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/761
Currently, Clutter does picking by drawing with Cogl and reading
the pixel that's beneath the given point. Since Cogl has a journal
that records drawing operations, and has optimizations to read a
single pixel from a list of rectangle, it would be expected that
we would hit this fast path and not flush the journal while picking.
However, that's not the case: dithering, clipping with scissors, etc,
can all flush the journal, issuing commands to the GPU and making
picking slow. On NVidia-based systems, this glReadPixels() call is
extremely costly.
Introduce geometric picking, and avoid using the Cogl journal entirely.
Do this by introducing a stack of actors in ClutterStage. This stack
is cached, but for now, don't use the cache as much as possible.
The picking routines are still tied to painting.
When projecting the actor vertexes, do it manually and take the modelview
matrix of the framebuffer into account as well.
CPU usage on an Intel i7-7700, tested with two different GPUs/drivers:
| | Intel | Nvidia |
| ------: | --------: | -----: |
| Moving the mouse: |
| Before | 10% | 10% |
| After | 6% | 6% |
| Moving a window: |
| Before | 23% | 81% |
| After | 19% | 40% |
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/154,
https://gitlab.gnome.org/GNOME/mutter/issues/691
Helps significantly with: https://gitlab.gnome.org/GNOME/mutter/issues/283,
https://gitlab.gnome.org/GNOME/mutter/issues/590,
https://gitlab.gnome.org/GNOME/mutter/issues/700
v2: Fix code style issues
Simplify quadrilateral checks
Remove the 0.5f hack
Differentiate axis-aligned rectangles
https://gitlab.gnome.org/GNOME/mutter/merge_requests/189
Add a function to check whether a point is inside a quadrilateral
by checking the cross product of vectors with the quadrilateral
points, and the point being checked.
If the passed quadrilateral is zero-sized, no point is ever reported
to be inside it.
This will be used by the next commit when comparing the transformed
actor vertices.
[feaneron: add a commit message and remove unecessary code]
https://gitlab.gnome.org/GNOME/mutter/merge_requests/189
This reverts commit f57ce7254d.
It causes crashes, https://gitlab.gnome.org/GNOME/mutter/issues/735, and
changes various expectations relied upon by the renderer code, and being
close to release, it's safer to revert now and reconsider how to remove
the pending swap counter at a later point.
Add a boolean parameter to the signal to inform the handler whether the
timeout completed successfully or not. This allows the shell to
gracefully end the pie timer animation and show a success animation when
the click happens.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/745
When a dwell click causes the pointer to move to another surface, a
synthetic event is generated which triggers another dwell click.
Make sure we ignore those to avoid dwell clicking twice in a raw.
Suggested-by: Carlos Garnacho <carlosg@gnome.org>
https://gitlab.gnome.org/GNOME/mutter/merge_requests/747
Restarting the dwell click immediately would result in a contant
animation showing.
Start dwell detection in its own timeout handler, which has the nice
effect of not constantly showing a dwell animation and also making sure
that the dwell click timeout is started when pointer movement stops.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/747
Sometimes the dwell timeout doesn't start again after quickly moving the
pointer. That happens if `should_stop_dwell` returns TRUE for the last
motion event we receive: It will stop the current timeout, but not start
a new one until we receive another event where the moved distance is
smaller than the threshold.
To fix this, always call `should_start_dwell` and `start_dwell_timeout`
instead of using an else-block, this makes sure we start a new dwell
timeout still during the same motion event that stopped the old one.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/746
And add the necessary glue so those initialize a X11 clutter backend.
This should get Clutter tests that are dependent on windowing to work
again, thus they were enabled back again.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/672
The end goal is to have all clutter backend code in src/backends. Input
is the larger chunk of it, which is now part of our specific
MutterClutterBackendNative, this extends to device manager, input devices,
tools and keymap.
This was supposed to be nice and incremental, but there's no sane way
to cut this through. As a result of the refactor, a number of private
Clutter functions are now exported for external backends to be possible.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/672
The end goal is to have all clutter backend code in src/backends. Input
is the larger chunk of it, which is now part of our specific
MutterClutterBackendX11, this extends to device manager, input devices,
tools and keymap.
This was supposed to be nice and incremental, but there's no sane way
to cut this through. As a result of the refactor, a number of private
Clutter functions are now exported for external backends to be possible.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/672
Mutter needs to know which framebuffer the paint nodes will be
drawn into, and using cogl_get_draw_framebuffer() directly is
not an option since ClutterRootNode only pushes the draw fb
at draw time.
Expose clutter_paint_node_get_framebuffer().
https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
Incompressible events already pass through unmodified, so queuing them
just wasted time and memory.
We would however like to keep the ordering of events so we can only
apply this optimization if the queue is empty.
This reduces the input latency of incompressible events like touchpad
scrolling or drawing tablets by up to one frame. It also means the same
series of events now arrives at the client more smoothly and not in
bursts.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/711
Until now we would:
1. Enqueue modifier key event on the stage.
2. Update device modifier state.
3. Dequeue and process modifier key event with NEW device modifier state.
But if we consider optimizing out the queuing in some cases then there
will become a problem:
1. Process modifier key event with OLD device modifier state.
2. Update device modifier state.
To correct the above we now do:
1. Update device modifier state.
2. Queue/process modifier key event with NEW device modifier state.
It appears commit dd940a71 which introduced the old behaviour was correct
in the need to update the device modifier state, but is at least no longer
correct (if it ever was) that it should be done after queuing the event.
If queuing is working, as it is right now, then it makes no difference
whether the device modifier state is updated before or after. Because both
cases will come before the dequeing and processing.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/711
Thanks to the now removed global/context grabs, we can move pointer and
keyboard grabs back home to where they belong.
While at it, also add handling of CLUTTER_TABLET_DEVICE devices to
`on_grab_actor_destroy` and `clutter_input_device_get_grabbed_actor`.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/536
If possible, GLib will try to use the va_marshaller to pass the signal
arguments, rather than unboxing into and out of a `GValue`. This is much
more performant and especially good for often-thrown signals.
The original bug even mentions Clutter performance issues as a drive to
implement the va_marshaller in GLib (see
https://bugzilla.gnome.org/show_bug.cgi?id=661140).
https://gitlab.gnome.org/GNOME/mutter/merge_requests/700
Some of the marshallers we generate in `clutter-marshal.list` are also
available in GLib, so we don't need to generate them ourselves. Even
more, by passing NULL to `g_signal_new` in these cases will actually
internally optimize this even more by also setting the valist
marshaller, which is a little bit faster than the regular marshalling
using `GValue` and libffi.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/700
`g_object_notify()` actually takes a global lock to look up the property
by its name, which means there is a performance hit (albeit tiny) every
time this function is called. For this reason, always try to use
`g_object_notify_by_pspec()` instead.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/703
Since commit 0eab73dc, actors are only allocated when they are actually
visible. While this generally works well, it breaks - because of *course*
it does - ClutterClones when the clone source (or any of its ancestors)
is hidden.
Force an allocation in that case to allow the clone's paint to work as
intended.
https://gitlab.gnome.org/GNOME/mutter/issues/683
The type has been deprecated, so stop using it. The easiest replacement
would be to add our own struct, but considering that separate name/value
arrays are easier to free (g_auto!) and we already do the split in one
place, go that route.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/689
