tree 29b0f7c913476543015f919f4e4ecb590cb61759
parent 55f4d308e5e8352bc5f41242bd8b19db431bc774
author Jeff Brown <jeffbrown@google.com> 1453852261 -0800
committer Jeff Brown <jeffbrown@google.com> 1453852261 -0800

Initial checkin of the new Mozart compositor.

The Mozart compositor is designed to support feed forward rendering of
scene graphs using scene version codes and node combinators to
determine synchronization behaviors.

A unique characteristic of Mozart is its ability to allow clients to
specify how to resolve situations where content is missing or not ready
by supplying alternative choices for what should be rendered.  The goal
is to avoid stalls by allowing more flexibility in specifying how scene
state updates are coordinated.

The scene graph consists of nodes of various types which represent
primitive operations such as filling a rectangle, drawing an image,
or embedding another scene.

The children of each node are composed according to the node's combinator
rule.  The default MERGE combinator rule simply draws all children
sequentially and refuses to draw anying if any of the children are blocked.
Other rules, such as FALLBACK, allow for alternative choices to be
made by the compositor at snapshot time based on what is available.

In the simplest cases, a client might provide substitute content to be
used in case the primary content is not yet ready.  In more elaborate
cases, a client might describe how an older version of the primary content
can be adapted to fit current demands, perhaps scaling or cropping it
as required.

The compositor itself is designed to be relatively unopinionated about
the contents that it is compositing.  Applications publish their scenes
and Mozart composites them, that's it.  High-level functionality such
as maintaining view embedding relationships or input dispatch are
exclusively handled by other components.

Mozart also offers:

- A relatively easy to use client interface.
- Vsync based scheduling.
- Hit testing (only partially implemented in this patch).
- Support for clients which use separate threads for event processing
  and rendering.
- Multi-display support (only partially implemented in this patch).

The rasterizer is currently implemented using Skia and Ganesh and runs
on a separate thread from the main engine.

This initial patch covers most of the essentials but there's plenty
more testing, optimization, and elaboration to do later.

This patch is followed by several others which serve to update the
view manager to use the new compositor, add various helpers,
update examples, and so on.

BUG=
R=abarth@google.com

Review URL: https://codereview.chromium.org/1552963002 .