Currently, this has been living in StWidget, moving that to Clutter
allows us to properly track the accessibility state changes in the
actors provided inside Clutter as well as simplifying things for a
future move from Atk.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4089>
This is intended to allow being notified about a stage update happening,
but painting didn't happen. This is possible today by using other
signals and keeping track of painting happened, but it saves us some
state tracking by just being told so.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4067>
In this scenario:
1. Only an "empty" content update (which results in no visible output
change) from client A arrives before the frame deadline, so a frame
event is sent for that at the deadline.
2. Another "empty" content update from client A results in a frame event
being scheduled for the next frame deadline.
3. A non-"empty" content update from client B arrives before start of
vblank, and the resulting output frame manages to hit the next
display refresh cycle.
The result was that the frame events from steps 1+2 were sent during the
same display refresh cycle, so the frame rate reported by client A was
higher than the display refresh rate.
This change fixes that, at the cost of frame events being sent out
later in the display refresh cycle if there's no new frame for the
next cycle.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3559
Fixes: 8f27ebf87eee ("clutter/frame-clock: Start next update ASAP after idle period")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3878>
Allow creating a queue of future times to tick at. This adds a new clock
state where we let the clock go idle, but will wake at a time in the
future to tick.
We can still schedule ticks while in this new state, but we're assured a
tick at or shortly after the scheduled time.
This will be used later by wayland code that schedules future presentation.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3355>
Allowing to disable font rendering integration, making it possible to
build Mutter without pango/harfbuzz/fribidi dependencies.
This commit also adds a new clutter-pango header that is used to include
pango specific bits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4106>
There is no real need to re-create a new cairo_font_options_t now that
the API is internal. Instead, create the font_options once and just
update it attributes.
Actors already register for the emitted font-changed signal to re-create
a new PangoContext.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4106>
When the `org.gnome.desktop.interface` schema is not found, currently
we were not initializing the font_options which means we needed to
handle that on the backend side. Instead, generate the font_options at
that moment.
As the settings are loaded the moment we assign a backend to the
settings `_clutter_settings_set_backend` which is called just after the
backend is constructed which is too early for any actor to use it for
creating a PangoContext, so the change is safe.
Also, as the font_options getter is only used in ClutterActor when
creating the PangoContext, drop the getter. As we might just store that
info somewhere else in the future.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4106>
Currently, we were first reading the settings, creating a FontSettings
struct and then mapping the string associated on that struct back to
their corresponding cairo type. A lot of dancing for not much benefits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4106>
The cairo_font_options is only meant to be consumed by ClutterActor when
creating a PangoContext and as those APIs are never used externally,
mark them private to not expose more cairo APIs.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4106>
As those properties are never set externally and just end up mapping the
gsettings values, in order to create a cairo_font_options_t.
Instead, simplify the whole thing and just create the
cairo_font_options_t from the resulting FontSettings.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4106>
Following previous commit, rename _clutter_paint_volume_init_static()
to clutter_paint_volume_init_from_actor(), and also
_clutter_paint_volume_copy_static() to
clutter_paint_volume_init_from_paint_volume().
Make clutter_paint_volume_init_from_paint_volume() follow the dst/src
semantic in its arguments, which also allows removing
_clutter_paint_volume_set_from_volume() which is exactly the same now.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4175>
And change clutter_paint_volume_free() to always free the paint volume.
Remove all calls to clutter_paint_volume_free() on static variables.
Having to call a free function on a static variable always seemed a bit
odd, and this genuinely confuses Coverity (and me).
Coverity CID: #1505838
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4175>
As is, ClutterImage is not really useful, it only serves for rendering a
CoglTexture as an actor. Shell, has a subclass that adds more features
that unfortunately cannot be upstreamed without bringing more gdk-pixbuf
usage inside libmutter, eg implementing GIcon/GLoadableIcon.
It also has requirements based on whether the image is symbolic or not.
Things that Clutter so far doesn't care about.
So just remove ClutterImage & let shells re-implement it themselves if
needed based on their needs.
Note, that once we have ClutterSnapshot, it should be straightforward to
write a custom actor that renders a CoglTexture or so.
This "un"fortunately means getting rid of various interactive tests that
either didn't compile at all or are not useful as is, like all the
remaining interactive tests.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4133>
Fixes leaks:
==1060013== 96 (32 direct, 64 indirect) bytes in 1 blocks are definitely lost in loss record 10,897 of 13,064
==1060013== at 0x4F81D57: g_type_create_instance (gtype.c:1929)
==1060013== by 0x4F64ABF: g_object_new_internal.part.0 (gobject.c:2606)
==1060013== by 0x4F66ADD: g_object_new_internal (gobject.c:2603)
==1060013== by 0x4F66ADD: g_object_new_with_properties (gobject.c:2769)
==1060013== by 0x4F67A30: g_object_new (gobject.c:2415)
==1060013== by 0x52F7C7B: clutter_color_state_new_full (clutter-color-state.c:339)
==1060013== by 0x4939CD0: update_color_state (meta-color-device.c:725)
==1060013== by 0x4939DDE: meta_color_device_new (meta-color-device.c:759)
==1060013== by 0x493CB7B: update_devices (meta-color-manager.c:205)
==1060013== by 0x493CE65: meta_color_manager_monitors_changed (meta-color-manager.c:264)
==1060013== by 0x49341CB: meta_backend_monitors_changed (meta-backend.c:371)
==1060013== by 0x4969150: meta_monitor_manager_notify_monitors_changed (meta-monitor-manager.c:1235)
==1060013== by 0x496928F: meta_monitor_manager_setup (meta-monitor-manager.c:1273)
==1060013==
==1060013== 96 (32 direct, 64 indirect) bytes in 1 blocks are definitely lost in loss record 10,898 of 13,064
==1060013== at 0x4F81D57: g_type_create_instance (gtype.c:1929)
==1060013== by 0x4F64ABF: g_object_new_internal.part.0 (gobject.c:2606)
==1060013== by 0x4F66ADD: g_object_new_internal (gobject.c:2603)
==1060013== by 0x4F66ADD: g_object_new_with_properties (gobject.c:2769)
==1060013== by 0x4F67A30: g_object_new (gobject.c:2415)
==1060013== by 0x52F7C7B: clutter_color_state_new_full (clutter-color-state.c:339)
==1060013== by 0x4939CD0: update_color_state (meta-color-device.c:725)
==1060013== by 0x4939DDE: meta_color_device_new (meta-color-device.c:759)
==1060013== by 0x493CB7B: update_devices (meta-color-manager.c:205)
==1060013== by 0x493CE65: meta_color_manager_monitors_changed (meta-color-manager.c:264)
==1060013== by 0x49341CB: meta_backend_monitors_changed (meta-backend.c:371)
==1060013== by 0x4969150: meta_monitor_manager_notify_monitors_changed (meta-monitor-manager.c:1235)
==1060013== by 0x496EA7D: meta_monitor_manager_rebuild (meta-monitor-manager.c:3968)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4149>
Fixes leak:
==5763== 96 (32 direct, 64 indirect) bytes in 1 blocks are definitely lost in loss record 10,901 of 13,065
==5763== at 0x4F81D57: g_type_create_instance (gtype.c:1929)
==5763== by 0x4F64ABF: g_object_new_internal.part.0 (gobject.c:2606)
==5763== by 0x4F66ADD: g_object_new_internal (gobject.c:2603)
==5763== by 0x4F66ADD: g_object_new_with_properties (gobject.c:2769)
==5763== by 0x4F67A30: g_object_new (gobject.c:2415)
==5763== by 0x52F7C46: clutter_color_state_new_full (clutter-color-state.c:339)
==5763== by 0x52F7C03: clutter_color_state_new (clutter-color-state.c:312)
==5763== by 0x52F7110: clutter_color_manager_get_default_color_state (clutter-color-manager.c:150)
==5763== by 0x52E7543: get_default_color_state (clutter-actor.c:17836)
==5763== by 0x52E765D: clutter_actor_unset_color_state (clutter-actor.c:17864)
==5763== by 0x52CF056: clutter_actor_constructor (clutter-actor.c:5646)
==5763== by 0x4F64DD3: g_object_new_with_custom_constructor (gobject.c:2524)
==5763== by 0x4F67275: g_object_new_internal (gobject.c:2604)
==5763== by 0x4F67275: g_object_new_valist (gobject.c:2945)
Fixes: 2693cac83a5c ("clutter/color-manager: Add a method to get the default color state")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4149>
Make create_transform_snippet method more consistent.
Abstract TransferFunction struct: convert it to ColorOpSnippet.
This transform snippet will be defined by these ColorOpSnippets.
These ColorOpSnippets are similar to the prescriptive DRM API for
color transformation.
A standard transform snippet would have as ColorOpSnippets:
1. eotf
2. luminance_mapping
3. color_space_mapping
4. inv_eotf
Update uniforms the same way the transform snippet is defined.
Update color transform key to consider how the transform snippet is
generated.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4144>
When creating a new color state from the primitives Colorimetry, EOTF
and Luminance; it is needed to previously check their tags to properly get
their values and avoid UB.
This check is duplicated and is a bit unreadable.
Using this new function helps keeping readability.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4144>
Most of the implementation at color state was specific to a color state
generated from parameters so move it to a new class Params.
In the next commits a new color state ICC class will be added.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4144>
The EOTFs snippets were only added when color states were not equal.
It makes more sense to only add the whole color transformation pipeline
in that case.
This makes the assumption to always append EOTFs snippets.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4144>
clutter_stage_schedule_update() sets the field `update_scheduled` to
`TRUE` as an optimization to make redundant updates a no-op. This failed
if there was a pending event and if the stage was not yet mapped.
What happened is:
* clutter_stage_schedule_update() is called
- ClutterStage::update_scheduled is set to TRUE
- frame clock scheduled
* frame clock dispatches
- frame is discarded early, no actual stage update happens
* device is created (e.g. virtual device from remote desktop session)
- `device-added` event reaches ClutterStage::event_queue
* stage is shown
- clutter_stage_schedule_update() is called
- ClutterStage::update_scheduled is TRUE
- ClutterStage::event_queue has events in it
- These two conditions means clutter_schedule_update() becomes a
no-op
At this point, no more updates will happen from
clutter_stage_schedule_update().
Fix this by resetting `ClutterStage::update_scheduled` to `FALSE` even
if the frame was discarded due to the stage not yet being mapped.
A test case is added that replicates the above descibed events.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3804
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4152>
When using a tablet tool in relative mode motion compression may
apply. Doing so drops the axes from the event, leading to a segfault
later when we're trying to broadcast_axis() an event without axes.
Fix this by making sure we copy the axes over during motion compression.
All but the wheel are absolute so we can just take them from the new
event but if we do have wheel data add them together and where the wheel
changes direction skip motion compression.
We can take a few shortcuts here because the clutter implementation
guarantees exactly CLUTTER_INPUT_AXIS_LAST axes so we only need to
put in warning checks in case that ever changes.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3766
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4117>
