[cairo] understanding the compositor

Chris Wilson chris at chris-wilson.co.uk
Wed Dec 16 07:30:14 PST 2015

On Wed, Dec 16, 2015 at 03:30:06PM +0100, Enrico Weigelt, metux IT consult wrote:
> Hi folks,
> I'm still struggling w/ understanding the compositor infrastructure.
> What is it actually doing ? How could I use it for the DRM backend(s) ?

It's a middle (helper) layer chosen by the backend to translate the high
level path into a geometry that the backend can handle. (It is meant to
be more flexible than cairo chosing to breakdown each operation into
common patterns; more composable if you will!)

It could convert the paths to a plain image that the backend composes.
Or it could convert the paths into a series of spans (scanline boxes).
Or it could convert the paths into a set of trapezoids.
Or it could convert the paths into a set of large boxes.

For each type of path; there is a preferred simpler representation. The
idea is that the helper transforms the incoming path to one of those
(which is chosen by the backend in selecting the helper) and that
simpler representation is then passed to a backend callback to render.

Often, the helper has to break the operation down into a series of
passes. (Though that is what we have tried hard to overcome.)

Or it may just be a set of glyphs.

Or the backend may just decide to handle the path/clip itself and skip
the helper.

> Several compositor types have an composite_boxes() function. How does
> that relate to i915/i965's composite_boxes() function ?

Should be close to identical, the concept is the same - composite pixel
aligned boxes, iirc.

Chris Wilson, Intel Open Source Technology Centre

More information about the cairo mailing list