Re: understanding the compositor
Chris Wilson <[email protected]>
| Newsgroups | gmane.comp.lib.cairo |
|---|---|
| Message-ID | <[email protected]> |
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 -- Chris Wilson, Intel Open Source Technology Centre -- cairo mailing list [email protected] http://lists.cairographics.org/mailman/listinfo/cairo