Represents a color with alpha channel.
Values are unorm (i.e. the valid range is [0,1]), and are in linear color
space. They are not gamma-corrected nor premultiplied.
A user-defined identifier for a particular piece of Content. See Content creation functions
(e.g. [CreateViewport], [CreateImage]) for more information.
The properties of an Image as defined by the client. These properties determine how an Image
uses the backing BufferCollection. See [CreateImage] for more information.
Zero identifiers: zero is never a valid identifier, for any of these types; each
Create* method rejects it. Unlike the classic API (where, e.g., [Flatland.SetContent]
accepts id 0 to clear a Transform’s content), Flatland2 never uses a zero id to express
clearing; where clearing is possible, it is expressed by omitting an optional field
(see [Flatland.SetTransformContent]).
The return type of [GetLayout]. This table contains most of the information necessary
for a client to decide how to layout their content in a Flatland session. This data may be
provided to the client before the command that creates the View is presented, so that the
client may lay out content properly before their first call to [Present].
Fields that a client needs in order to produce its next frame, returned in
[OnNextFrameBegin]. Each field is guaranteed to be set and contain valid information.
All arguments are optional; default values will be provided if they are absent.
By default, the resulting Flatland will behave identically to connecting
to the [Flatland] service instead of connecting via the factory.
The protocol endpoints bound to a Flatland ViewCreationToken. These protocols operate on the
View that ViewCreationToken created in the Flatland session.
The properties of a Viewport as defined by the parent. This data, along with the set of attached
Transforms, will be used to compute the LayoutInfo for the View of the Viewport.
ViewportProperties must have logical_size set at least once. This is the initial size that
will drive the layout of the child.
A protocol that provides information about a particular child View which is attached to the
Viewport owned by the parent client; connections to this protocol are estabished in
[CreateViewport]. Since a Flatland session may contain any number of Viewports, each of
which may or may not be attached to a transform, the client can maintain connections to an
equal number of ChildViewWatcher instances.
This API connects to the singleton “primary display”, and allows a tree of Flatland content to
be attached underneath. Only one FlatlandDisplay client connection is allowed at one time.
Each Flatland session contains a Graph, which consists of a set of objects, and the
relationships between those objects. The client can specify a subset of those objects
(specifically, the directed acyclic graph starting at the root transform) to be presented as
content to some kind of output – usually, a display.
In Flatland, the +X axis is to the right and +Y axis is down. There is no notion of a Z axis.
Due to the lack of a Z axis, there is no mathematical notion of “handedness” (either right or
left) with respect to rotation. Thus, we define a counter-clockwise rotation in the same way
as if a skeuomorphic clock were to be displayed on the screen, with the hands of said clock
moving in a CCW motion from the POV of the observer.
ParentViewportWatchers will be informed when they are actively attached to a output display
(either directly, or through a chain of parent Viewports) and when they are not. Until they are
connected to a display, some pieces of information (such as pixel scale) may be unavailable.
A protocol that provides information about the parent Viewport attached to a Flatland session’s
sole View. Although Flatland sessions can have at most one view, it is possible to have
multiple ParentViewportWatchers during the brief transition period when replacing the session’s
View with another, e.g. via [CreateView]. During this period, certain updates may be
duplicated and sent to each ParentViewportWatcher connection.
This protocol provides a low-level ScreenCapture API for clients to use.
ScreenCapture clients should familiarize themselves with the
[fuchsia.sysmem/BufferCollection] and [fuchsia.ui.composition/Allocator] protocols
as those are necessary to create the BufferCollections and images ScreenCapture uses.
A fence that will be signaled when the associated resource is ready for Scenic to use.
For context-specific usage info, refer to the method the fence appears in.