Allow only specific files to use those deprecated APIs making
it easier to find where deprecated APIs are still in use
and avoid introducing new usages without being noticed
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3400>
Currently, json-glib is used for two things:
- For loading scripts, nothing seems to use that in real life other
than some tests
- For debugging paint nodes
For now, the PR drops the first use case and only require json-glib
if it is a debug build
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3354>
This struct contains the pressed/latched/locked set of modifiers applying
to the event, and may be filled in by backends generating those events.
Other places where we forward modified key events, state may be normally
obtained from the original event.
Since this constructor is used in a variety of places, this commit
updates them all in one go.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3369>
`clutter_actor_destroy()` queues a stage update. Under certain
circumstances - i.e. when run in a very slow container - this can race
with the stage update triggered by the following
`clutter_virtual_input_device_notify_button()`, occasionally resulting in
`wait_stage_updated()` to return before the
`on_event_return_propagate()` callbacks ran, making the test fail.
This notably became more common since
8f27ebf87e (clutter/frame-clock: Start next update ASAP after idle period)
landed.
Thus wait for a stage update to happen after `clutter_actor_destroy()`,
preventing the race.
Fixes: f6da583d06 (tests/clutter/event-delivery: Add tests for implicit grabbing)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3332>
Instead of g_get_monotonic_time. This makes sure last_presentation_time_us
advances by refresh_interval_us.
Doesn't affect test results at this point, but it will with the next
commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3174>
Except for the tests that launches `mutter`, use a custom shell
implementation. It's roughly a copy of default.c with some cleanups on
top. A custom shell allows for a bit more freedom when doing testy
things.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3185>
With the ClutterEvent subtype structs sealed, this remains the only useful
struct type that is now usable on the Javascript side. Make all
ClutterActorClass event vmethods use ClutterEvent, and update all users
to this change.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3163>
An input only grab is a ClutterGrab on the stage that doesn't have an
explicit actor associated with it. This is useful for cases where event
should be captured as if focus was stolen to some mysterious place that
doesn't have anything in the scene graph that represents it.
Internally, it's implemented using a 0x0 sized actor attached directly
to the stage, and a clutter action that consumes the events. An
input-only grab takes a handler, user data and a destroy function for
the user data. These are handed to the ClutterAction, which handles the
actual event handling.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
If we call schedule(), which will schedule an update some time in the
future, and then schedule_now(), we should reschedule the frame clock to
update immediately, and not some time in the future.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
That means before-update, prepare-paint, before-paint, paint-view, after-paint,
after-update. While yet to be used, it will be used as a transient frame
book keeping object, to maintain object and state that is only valid
during a frame dispatch.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2795>
Flushing the input thread might implicitly iterate the mainloop, and thus
update the stage while still inside the clutter_test_flush_input() call.
This means the stage update has already happened when we call
wait_stage_updated(), and that's why we call clutter_stage_schedule_update()
there currently.
This clutter_stage_schedule_update() call is not necessary though, instead
we can flush the input thread from inside wait_stage_updated() after
setting was_updated to FALSE.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2792>
* creating an actor will result in it being assigned a color state
with the color space sRGB
* creating an actor with a color state passed will result in that
color state being returned
* changing an actor's color state makes that happen
* changing an actor's color state to NULL ends up with it being
changed back to a color state with the sRGB color space
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2443>
The Cogl feature was removed a while back, while Clutter just hard coded
it to TRUE. Lets remove the confusion that GLSL isn't supported and just
remove the (dead) fallback paths.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2015>
Since we want these accessed from bindings this must be a boxed
type. This has the side effect of making ClutterGrab a refcounted
object, since we want to avoid JS from pointing to freed memory
and maybe causing crashes if misusing the object after dismiss.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2099>
The final tick of a timeline is >= its duration, but when using ticks that
are slightly in the future ("next presentation time") this means the final
tick will execute and complete the timeline up to one frame interval before
the timestamp of that final tick.
For the single clock test we now just check if the overall duration is
within one frame of the expected timeline duration.
The dual clock (switching) test needs a threshold of two frames because
starting each new clock creates a phase shift (error) of up to one frame.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2161>
This test is injecting input events without checking the correct stage/
device state. Wait for the pointer to enter the stage, so the event gets
correctly forwarded across.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
This will require some symbol exporting, but the benefit is that have
better control of what external test cases can do in terms of creating
more testing specific contexts.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
This fixes the interpolate test to not use the wall clock, but the
monotonic clock. It also cleans up the timestamp granularity naming, so
that the different granularity is clearer, as in the test, different
timestamps have different granularity.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1751>
This more or less rewrites this test so that it explicitly tests the
"interpolation" when a timeline loops, i.e. that if something occupies
the thread when a timeline was supposed to have looped, we end up in the
right place "in the middle" of the next timeline cycle.
The test more or less does this:
* Start a 3 second looping timeline
* Sleep so that we're in the middle of the first cycle
* Sleep again so that we end up in the middle of the next cycle
The semantics checked are that we see the following frames:
* The first frame with timestamp 0
* The second frame in the middle of the first cycle (timestamp ~= 1.5
sceonds)
* The third frame in the end of the first cycle (timestamp == 3.0
seconds)
* The fourth frame, first in the second cycle, with timestamp ~= 1.5
seconds)
This means we can increase the "grace period" to the double (from 0.5 s
to 1 s), while at the same time decrease the time spent running the test
(from 10 s to 4.5 s). This should hopefully make the test less flaky,
especially in slower runners, e.g. aarch64.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1751>
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>
