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>
The stage view color state is not the output color state but usually a
linear version of it. For direct scanout, we need the view color state
to match the output color state instead.
Fixes: 20c7653d49 ("compositor-view/native: Don't scan out surface with color state mismatch")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4196>
In order to ensure consistent behavior with the composited path as well as across
different KMS drivers. In the future we'll want to use other values as well,
requested by client via the upcoming color representation protocol.
Note that right now KMS drivers default to different values. Most use BT709 and
narrow range, notably Intel and AMD, but some others do not.
BT709/narrow is arguably a much better default than BT601/narrow as the former is
used for most contemporary video content and the later more for still images.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4204>
New protocol that allows a client to require that a previously flagged
content update must be presented before a content update can be applied.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3355>
Allow a transaction to have a timing constraint.
Any transaction with a timing constraint will be deferred at its initial
commit, without testing the target time. The timing constraints are cleared
later in an on_before handler immediately before repaint.
The new frame clock api to schedule later ticks is use to ensure we get an
appropraitely timed tick to clear the constraint.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3355>
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>
By introducing a BufferImpl that handles the buffer
allocation/de-allocation bits and making the driver responsible for
creating the correct impl.
This allow moving various Buffer specific vfuncs from Driver as well as
getting rid of the gl_handle field from Buffer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4181>
This consolidates duplicate code in meta_drm_buffer_gbm_blit_to_framebuffer
to use the newly added meta_drm_buffer_gbm_create_native_blit_image, which
also has the side-effect of caching creation of the EGLImage per GBM BO.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4027>
Creating an EGLImage is rather expensive and is taking the bulk of the
time the secondary GPU copy path is using for each frame. By caching
these per GBM BO we avoid this expensive recreation, which seems to
significantly improve FPS throughput in these scenarios, e.g. an
AMD or Intel iGPU with an NVIDIA dGPU.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4027>
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>
