This uses MetaCompositorViewNative to find a candidate surface for
scanout and to keep track of it separately for each view, effectively
allowing each CRTC to use a different buffer for direct scanout.
There are three parts for potentially assigning a buffer for direct
scanout at the compositor level:
1. Finding a candidate surface actor on the view (if any)
2. Attempting to assign the candidate's buffer for direct scanout
3. Updating references relating to the scanout candidate as needed
The three parts were moved in their entirety from being handled by the
MetaCompositorNative to being handled by the MetaCompositorViewNative.
As part of this transition, the logic was also slightly refactored so
that each of the three parts is handled by its own helper function.
This allowed to avoid the use of "goto" statements and hopefully make
the logic easier to read and follow.
The first part mentioned above was changed in this commit to make use
of the new meta_compositor_view_get_top_window_actor () API to get the
top window actor in the view instead of the top window actor on all
views.
The second part and third parts mentioned above weren't changed other
than being done in the context of a view instead of globally.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2526>
All of the checks this function performed internally were already
done before calling it, making it a simple wrapper function without a
meaningful purpose.
Removing this function also reduces the chance of additional checks
being added to the MetaSurfaceActor after it is already chosen as a
scanout candidate.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2526>
This class is meant to hold logic specific to the native backend
in the context of a MetaCompositorView.
Its addition requires making MetaCompositorView inheritable, and an
addition of a virtual function which allows each compositor to create
its own MetaCompositorView instance.
In the case of the MetaCompositorNative, a MetaCompositorViewNative
is created. In all other cases, a MetaCompositorView is created.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2526>
The idea is that the state of the MetaCompositorView shall be
up-to-date only in specific scenarios, thus allowing operations
performed on it to be queued and aggregated to be handled in the
right time, and only if they are still necessary.
For example, in a following commit, the top window actor in each
view will be planned (if needed) only once before painting a frame,
rendering the top window actor in the MetaCompositorView potentially
stale in all other times.
Similarly, if a MetaCompositorView is destroyed before the beginning
of the frame, a queued operation to update its top window actor can be
discarded.
As an interface segragation measure, and as part of an attempt to
avoid the use of g_return_if_fail () to check the validity of the
MetaCompositorView's state in multiple places (which is still prone to
human error), the interfaces through which a MetaCompositorView is
made available would only ones where it's state is gurenteed to be
up-to-date.
Specifically, this commit gurentees that the state of the
MetaCompositorView would be up-to-date during the before_paint () and
after_paint () vfuncs exposed to child classes of the MetaCompositor.
The frame_in_progress variable will be used in a following commit to
guarantee that the MetaCompositorView's state is not invalidated during
this time.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2526>
This replaces the API to get the topmost surface actor with an API to
get the surface actor that could be a candidate for direct scanout. The
advantage of this is that it allows X11 and Wayland specific
restrictions for these actors.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2409>
Before scanning out the surface of a native client we have
to check the following attributes that influence the
relationship between buffer and the defined result on screen:
- buffer scale
- buffer transform
- viewport
In the future we can loose these checks again in cases where the
display hardware supports the required operations (scaling, cropping
and rotating).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2276>
If a Wayland subsurface is the topmost actor, consider in for
scanout as well. This will extend our scanout capabilities to apps
like Firefox
While on it, correct a unnessary type check to a NULL check.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2211>
A first step towards abandoning the CoglObject type system: convert
CoglFramebuffer, CoglOffscreen and CoglOnscreen into GObjects.
CoglFramebuffer is turned into an abstract GObject, while the two others
are currently final. The "winsys" and "platform" are still sprinkled
'void *' in the the non-abstract type instances however.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1496
Replace the default master clock with multiple frame clocks, each
driving its own stage view. As each stage view represents one CRTC, this
means we draw each CRTC with its own designated frame clock,
disconnected from all the others.
For example this means we when using the native backend will never need
to wait for one monitor to vsync before painting another, so e.g. having
a 144 Hz monitor next to a 60 Hz monitor, things including both Wayland
and X11 applications and shell UI will be able to render at the
corresponding monitor refresh rate.
This also changes a warning about missed frames when sending
_NETWM_FRAME_TIMINGS messages to a debug log entry, as it's expected
that we'll start missing frames e.g. when a X11 window (via Xwayland) is
exclusively within a stage view that was not painted, while another one
was, still increasing the global frame clock.
Addititonally, this also requires the X11 window actor to schedule
timeouts for _NET_WM_FRAME_DRAWN/_NET_WM_FRAME_TIMINGS event emitting,
if the actor wasn't on any stage views, as now we'll only get the frame
callbacks on actors when they actually were painted, while in the past,
we'd invoke that vfunc when anything was painted.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/903
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
The repaint callbacks are not tied to repaint, thus a bit misleading.
What the functionality in the pre/post-paint callbacks here cares about
is when actually painting; the non-painting related parts has already
moved out to a *-update signal.
This also renames the related MetaWindowActorClass vfuncs, to align with
naming convention of the signals that it listens to.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
We would get the MetaDisplay from the backend singleton before creating
the MetaCompositor, then in MetaCompositor, get the backend singleton
again to get the stage. To get rid of the extra singleton fetching, just
pass the backend the MetaCompositor constructors, and fetch the stage
directly from the backend everytime it's needed.
This also makes it available earlier than before, as we didn't set our
instance private stage pointer until the manage() call.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1289
Try to bypass compositing if there is a fullscreen toplevel window with
a buffer compatible with the primary plane of the monitor it is
fullscreen on. Only non-mirrored is currently supported; as well as
fullscreened on a single monitor. It should be possible to extend with
more cases, but this starts small.
It does this by introducing a new MetaCompositor sub type
MetaCompositorNative specific to the native backend, which derives from
MetaCompositorServer, containing functionality only relevant for when
running on top of the native backend.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
