Skip to content

Introduce weston_paint_node

Pekka Paalanen requested to merge pq/weston:mr/paint-node into main

See #494 for the motivation of this MR.

Color management work in !582 (merged) needed to handle state keyed by surface-output pairs, and originally built a private mechanism for it. Paint nodes replace that private mechanism.

Paint nodes are a libweston core mechanism for having state keyed by surface-view-output triplets. Since a view always has exactly one surface associated, it is really about view-output pairs that are going through repaints, since a view must be created and mapped before a paint node materializes. Likewise, if any of the surface, view, or output disappears, the corresponding paint nodes are torn down.

In future, paint node will be useful for caching surface-output or view-output pair dependent data:

  • damage regions (make overlapping outputs work)
  • color transformations
  • backend-specific bookkeeping (e.g. DRM KMS plane assigments)
  • per-output repaint lists
  • surface geometry transformed into output space

First, this MR introduces the paint node data structure and creates them as part of weston_compositor_build_view_list().

Second, a per-output z-ordered paint node list is introduced. It is identical to the current weston_compositor::view_list, but in the future it shall not contain nodes for views that are not relevant for the output, e.g. off-screen or completely occluded.

Third, everything related to output repaint that iterated through weston_compositor::view_list are converted to use the z-ordered paint node list. Other uses of view_list are commented on why they cannot use paint node lists.

This should set the stage far enough that !582 (merged) can make use of paint nodes, and all the follow-up work in #494 has a good basis to build on.

This is probably as far as I can go with this without needing to write more tests.

Merge request reports