mutter/src/compositor
Jonas Ådahl 49c8d42317 clutter: Introduce paint contexts
When painting, actors rely on semi global state tracked by the state to
get various things needed for painting, such as the current draw
framebuffer. Having state hidden in such ways can be very deceiving as
it's hard to follow changes spread out, and adding more and more state
that should be tracked during a paint gets annoying as they will not
change in isolation but one by one in their own places. To do this
better, introduce a paint context that is passed along in paint calls
that contains the necessary state needed during painting.

The paint context implements a framebuffer stack just as Cogl works,
which is currently needed for offscreen rendering used by clutter.

The same context is passed around for paint nodes, contents and effects
as well.

In this commit, the context is only introduced, but not used. It aims to
replace the Cogl framebuffer stack, and will allow actors to know what
view it is currently painted on.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
2019-12-03 19:02:14 +00:00
..
2019-06-20 18:25:04 +02:00
2018-11-06 17:17:36 +01:00
2019-08-19 08:44:58 +00:00
2018-11-06 17:17:36 +01:00
2018-11-06 17:17:36 +01:00
2019-01-04 09:32:58 -02:00

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.