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
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
