docs/concepts/ui/scenic/views.md

# View System

One of Scenic's primary responsibilities is being the arbiter of all
[Views](/docs/glossary#view) used to compose UI in a running Fuchsia system.

The set of Scenic APIs which [UI Clients](/docs/concepts/ui/ui-client.md) use
to create, destroy, and modify Views are together called the
[View System](/docs/contribute/governance/rfcs/0147_view_system.md).

## View

A [View](/docs/glossary#view) is the fundamental unit of UI organization on Fuchsia.

UI clients manage Views by interacting with Scenic, which maintains all Views on their behalf
and assembles the Views into a coherent View Tree.

Each View defines a 2-dimensional coordinate system; UI clients embed graphical content within
a View's coordinate system and receive input events according to the same.

It is not possible for a UI client to present graphical content to the display without
embedding it in a View first.

## Viewport

UI clients can embed other Views within their own View by asking Scenic to create an object
called a Viewport; this Viewport is intrinsically linked to a given View which it "hosts".

The hosted View can be, and often is, owned by another UI client in a different component.

## View Tree {#view-tree}

Using Views and Viewports UI clients can collaborate to build a global, distributed tree of
content for Scenic to dispatch for rendering and query for hit testing.

This global tree of Views is called the View Tree and Scenic is responsible for maintaining it
on behalf of UI clients.

All content rendered by Scenic is encapsulated within a View.  Each input event delivered to a
UI Client is relative to a View owned by that client.

## View Tree relationship to display and input

Scenic presents the Root View of the View Tree to the display, meaning the root view has
dimensions identical to the display dimensions.

Scenic partitions the display space between Views based on the sizes and positions of their
coordinate systems.

Scenic's hit testing system operates according to this partitioning, so that UI clients
receive input events according to the sizes and positions of their Views.

## View Tree rules

* No dependency cycles allowed.
* Each View may only have one other View as a parent.
* Each View is only aware of its own coordinate system.
* Each View can control the coordinate system of hosted child Viewports via translations,
rotations, and scales.