If possible, GLib will try to use the va_marshaller to pass the signal
arguments, rather than unboxing into and out of a `GValue`. This is much
more performant and especially good for often-thrown signals.
The original bug even mentions Clutter performance issues as a drive to
implement the va_marshaller in GLib (see
https://bugzilla.gnome.org/show_bug.cgi?id=661140).
https://gitlab.gnome.org/GNOME/mutter/merge_requests/700
Some of the marshallers we generate in `clutter-marshal.list` are also
available in GLib, so we don't need to generate them ourselves. Even
more, by passing NULL to `g_signal_new` in these cases will actually
internally optimize this even more by also setting the valist
marshaller, which is a little bit faster than the regular marshalling
using `GValue` and libffi.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/700
`g_object_notify()` actually takes a global lock to look up the property
by its name, which means there is a performance hit (albeit tiny) every
time this function is called. For this reason, always try to use
`g_object_notify_by_pspec()` instead.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/703
Since commit 0eab73dc, actors are only allocated when they are actually
visible. While this generally works well, it breaks - because of *course*
it does - ClutterClones when the clone source (or any of its ancestors)
is hidden.
Force an allocation in that case to allow the clone's paint to work as
intended.
https://gitlab.gnome.org/GNOME/mutter/issues/683
The type has been deprecated, so stop using it. The easiest replacement
would be to add our own struct, but considering that separate name/value
arrays are easier to free (g_auto!) and we already do the split in one
place, go that route.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/689
Glib stopped providing any fallback implementations on systems without
memmove() all the way back in 2013. Since then, the symbol is a simple
macro around memmove(); use that function directly now that glib added
a deprecation warning.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/689
Currently nothing in the clutter machinery prevents hidden portions
of the actor tree from calling queue_relayout() (and having it fully
honored).
But that allocation should not be necessary till the actor is shown,
and one of the things we do on show() is queueing a relayout/redraw
after flagging the actor as visible.
We can simply defer clutter_actor_allocate() calls till that show()
call, and leave the needs_allocate and other flags set so we ensure
the allocation is properly set then.
This should cut down some needless operations when invisible portions
of the actor tree change indirectly due to user interaction, or due
to background activity.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/677
Clutter has two motion event toggles: one in the global context, and
one per stage. The global one is deprecated, and currently unused.
Remove the global motion event handling.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/666
The “togglekeys” setting is to emit a sounds whenever the state of one
of the modifiers keys (CAPS lock, NUM Lock, SCROLL lock) is changed, it
has nothing to do with the rest of the accessibility settings.
Therefore, there is no need to reset the various timers used by
accessibility whenever the “togglekeys” setting is changed.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/614
ClutterStage:after-paint now does not guarantee a valid
implicit framebuffer pushed to the stack. Instead, use
the new 'paint-view' signal, that is emitted at a point
in the drawing routine where a framebuffer is pushed.
In addition to that, stop using the implicit framebuffer
API and port the actor-shader-effect test to read from
the view's framebuffer directly.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/623
Now that ClutterStageView is embraced as part of the public
set of Clutter classes, is it possible to give consumers
of this API more information and control over the drawing
routines of ClutterStage.
Introduce ClutterStage:paint-view, a signal that is emitted
for painting a specific view. It's defined as a RUN_LAST
signal to give anyone connecting to it the ability to run
before the view is actually painted, or after (using the
G_CONNECT_AFTER flag, or g_signal_connect_after).
This signal has a corresponding class handler, which allows
Mutter to have much finer control over the painting routines.
In fact, this will allow us to implement a "paint phase watcher"
mechanism in the following patches.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/623
ClutterStage:after-paint is supposed to be emitted after all
painting is done, but before the frame is finished. However,
as it is right now, it is being emitted after each view is
painted -- on multi-monitor setups, after-frame is being
emitted multiple times.
Send after-paint only once, after all views are painted and
before finishing the frame.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/623
As a compositor toolkit, it makes sense to allow consumers
of Clutter interact with the stage views themselves. As such,
ClutterStageView should be a public class.
As such, it is now included in clutter.h and should not be
included directly.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/623
When libwacom is configured disabled, this error appears:
../clutter/clutter/x11/clutter-input-device-xi2.c: In function ‘clutter_input_device_xi2_finalize’:
../clutter/clutter/x11/clutter-input-device-xi2.c:122:7: error: ‘device_xi2’ undeclared (first use in this function)
if (device_xi2->inhibit_pointer_query_timer)
Fix it with the "obvious" solution.
This code was added in c1303bd642.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/611
When a user moves their cursor the perceived behaviour is that it will
pick what is under the cursor. However this isn't how picking works.
Picking does a virtual redraw of the screen, so in some cases what gets
picked isn't the same as what the user could see on the previous frame.
It more represents what will be drawn on the next frame than what is on
screen at present.
It may be unsafe to change these semantics, and they are useful anyway.
Just document it better.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/214
After 4faeb12731, the maximum time allowed for an update to happen
is calculated as:
max_render_time_allowed = refresh_interval - 1000 * sync_delay;
However, extremely small refresh intervals -- that come as consequence
to extremely high refresh rates -- may fall into an odd numerical range
when refresh_interval < 1000 * sync_delay. That would give us a negative
time.
To be extra cautious about it, add another sanity check for this case.
Change suggested by Jasper St. Pierre.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/363
The presentation timing logic (via `master_clock_get_swap_wait_time`) now
works unconditionally. By "works" we mean that a result of zero from
`master_clock_get_swap_wait_time` actually means zero now. Previously
zero could mean either a successful result of zero milliseconds or that
the backend couldn't get an answer. And a non-zero result is the same as
before.
This works even if the screen is "idle" and even if the backend doesn't
provide presentation timestamps. So now our two fallback throttling
mechanisms of relying on `CLUTTER_FEATURE_SWAP_THROTTLE` and decimating
to `clutter_get_default_frame_rate` can be deleted.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/406 and
https://bugzilla.gnome.org/show_bug.cgi?id=781835https://gitlab.gnome.org/GNOME/mutter/merge_requests/363
If `last_presentation_time` is zero (unsupported) or just very old
(system was idle) then we would like to avoid that triggering a large
number of loop interations. This will get us closer to the right answer
without iterating.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/363
That could happen if the backend did not provide presentation timestamps,
or if the screen was not changing other than the hardware cursor:
if (stage_cogl->last_presentation_time == 0||
stage_cogl->last_presentation_time < now - 150000)
{
stage_cogl->update_time = now;
return;
}
By setting `update_time` to `now`, master_clock_get_swap_wait_time()
returns 0:
gint64 now = g_source_get_time (master_clock->source);
if (min_update_time < now)
{
return 0;
}
else
{
gint64 delay_us = min_update_time - now;
return (delay_us + 999) / 1000;
}
However, zero is a value unsupported by the default master clock
due to:
if (swap_delay != 0)
return swap_delay;
All cases are now handled by extrapolating when the next presentation
time would be and calculating an appropriate update time to meet that.
We also need to add a check for `update_time == last_update_time`, which
is a situation that just became possible since we support old (or zero)
values of `last_presentation_time`. This avoids getting more than one
stage update per frame interval when input events arrive without
triggering a stage redraw (e.g. moving the hardware cursor).
https://gitlab.gnome.org/GNOME/mutter/merge_requests/363
Instead of crazy refresh rates >1MHz falling back to 60Hz, just honour
them by rendering unthrottled (same as `sync_delay < 0`). Although I
wouldn't actually expect that path to ever be needed in reality, it just
ensures an infinite `while` loop never happens.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/363
