mirror of
https://github.com/brl/mutter.git
synced 2025-02-10 18:34:09 +00:00
4736f873f2
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>
Intro
=====
In general, the compositor splits the window from the contents of
the window from the shape of the window. In other words, a window
has contents, and the contents of the window have a shape. This is
represented by the actor hierarchy:
+--------------------------------------+
| MetaWindowActor |
| +----------------------------------+ |
| | MetaSurfaceActor | |
| | +------------------------------+ | |
| | | MetaShapedTexture | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | +------------------------------+ | |
| +----------------------------------+ |
+--------------------------------------+
Surfaces may also contain subsurfaces. The MetaWindowActor and
MetaSurfaceActor subclasses that will be created depend on the client
type, and the display server type.
## Subsurfaces
Additionally, there is also the case of subsurfaces: surfaces that
are child of other surfaces. That is also represented in the actor
hierarchy by having one or many MetaSurfaceActors (the subsurfaces)
added as children of a parent MetaSurfaceActor. There are no limits
to how many subsurfaces a surface may have. With subsurfaces, the
actor hierarchy looks like this:
MetaWindowActor
↳ MetaSurfaceActor (surface)
↳ MetaShapedTexture
↳ MetaSurfaceActor (subsurface)
↳ MetaShapedTexture
↳ MetaSurfaceActor (sub-subsurface)
↳ MetaShapedTexture
↳ MetaSurfaceActor (subsurface)
↳ MetaShapedTexture
In this example, the main surface has 2 subsurfaces. One of these
subsurfaces contains a subsurface as well.
All MetaWindowActors contain at least one MetaSurfaceActor, and all
MetaSurfaceActors contain a MetaShapedTexture.
## Client and compositor
MetaWindowActor and its subclasses represent the client window's
type. A X11 client will have a MetaWindowActorX11 representing it,
and a Wayland client will have a MetaWindowActorWayland.
On the compositor side, the surface where the contents of the window
are drawn into are represented by MetaSurfaceActor subclasses. On a
Wayland session, windows are backed by a MetaSurfaceActorWayland
surface, whereas on X11 sessions, by MetaSurfaceActorX11.
XWayland windows are X11 client windows (MetaWindowActorX11) backed
by Wayland surfaces (MetaWindowActorWayland).
Env Vars
========
MUTTER_DISABLE_MIPMAPS - set to disable use of mipmaped windows.