ATTENTION: This document describes the behavior of Scenic's GFX API which is currently being replaced by the Flatland API. Workstation currently uses Flatland only, and Smart Display will be converted to use Flatland as well. If working with Flatland, please refer to the Flatland documentation.
Gfx is Scenic's legacy 3D API. Like other APIs such as Flatland, it provides a retained-mode scene graph consisting of content that is independently generated and linked together by its clients. Like Flatland, it supports Scenic's core responsibilities of Composition, Rendering, Scheduling, and Diagnostics.
A unique feature of the 3D objects managed by the Gfx API is that they are rendered within a unified lighting environment. This means that the object can cast shadows or reflect light onto each other, even if the originating processes have no knowledge of each other.
The fuchsia.ui.scenic.Session FIDL protocol is the primary API used by clients of Scenic to contribute graphical content in the form of Resources. Each session has its own resource table and is unable to directly interact with resources belonging to other sessions.
Each session provides the following operations:
When a session is destroyed, all of its resources are released and all of its links become inoperable.
Resources represent scene elements such as nodes, shapes, materials, and animations that belong to particular Sessions.
The list of Scenic resources is described by the API: //sdk/fidl/fuchsia.ui.gfx/resources.fidl
Clients of Scenic generate graphical content to be rendered by queuing and submitting operations to add, remove, or modify resources within their session.
Each resource is identified within its session by a locally unique id which is assigned by the owner of the session (by arbitrary means). Sessions cannot directly refer to resources that belong to other sessions (even if they happen to know their id) therefore content embedding between sessions is performed using Link objects as intermediaries.
To add a resource, perform the following steps:
Certain more complex resources may reference the ids of other resources within their own definition. For instance, a Node references its Shape thus the Shape must be added before the Node so that the node may reference it as part of its definition.
To modify a resource, enqueue one or more operations to set the desired properties in the same manner used when the resource was added.
The remove a resource, enqueue an operation to remove the resource.
Removing a resource causes its id to become available for reuse. However, the session maintains a reference count for each resource that is internally referenced. The underlying storage will not be released (and cannot be reused) until all remaining references to the resource have been cleared and until the next frame that does not require the resource has been presented. This is especially important for Memory resources. See also Fences.
This process of addition, modification, and removal may be repeated indefinitely to incrementally update resources within a session.
A Node resource represents a graphical object that can be assembled into a hierarchy called a node tree for rendering.
Here is a walk-through on how Scenic internally manages the lifecycle of Node-like resources and embedded Views.
A Scene resource combines a tree of nodes with the scene-wide parameters needed to render it. A Scenic instance may contain multiple scenes but each scene must have its own independent tree of nodes.
A scene resource has the following properties:
In order to render a scene, a Camera must be pointed at it.
Compositors are resources that come in two flavors: DisplayCompositor and ImagePipeCompositor; their job is to draw the content of a LayerStack into their render target. For DisplayCompositor, the target display may have multiple hardware overlays; in this case the compositor may choose associate each of these with a separate layer, rather than flattening the layers into a single image.
A LayerStack resource consists of an ordered list of Layers. Each layer can contain either an Image (perhaps transformed by a matrix), or a Camera that points at a Scene to be rendered (as described above).
Scenic manages a global scene graph in a three dimensional space. Some of the characteristics of this space are defined by Scenic itself, whereas some are defined by the root presenter or even other clients.
Units are configured by the root presenter. The default root presenter uses a device-independent scalable unit called “pips” for the root space. See Units and Metrics for details. What units are used for your view space depends on what transforms are applied to your view by your parent.
The Scenic world space is a right handed Cartesian space. It is configured by the root presenter which configures the view and projection parameters of the camera. The default root presenter will put the origin at the top left of the screen and make +X point right, +Y point down, and +Z point into the screen.
Ultimately the space of a given view depends on what transforms are applied to it by its parent View and the parent View‘s parent and so on. If no rotation transform is applied and all scale transforms are positive along all axes then the View’s axes will align with the axes of the root presenter and the handedness will match.
The bounds of the root view are defined by a min and a max point as follows:
View Bounds shows how to set up your view bounds, how to debug them with wireframe rendering, and explains how view bounds interact with hit testing.
Frame scheduling explains how the frame scheduling API work and contains examples of how to use it.
{# TODO(fxbug.dev/24431): Talk about synchronization. #}
//src/ui/examples; each example has documentation describing what it does and how to run it. There examples for both the Flatland and Gfx APIs.Scenic has convenience wrapper libraries for some languages. These can be used instead of using the FIDL API directly.
The following files define and document the collection of FIDL protocols that make up Scenic.