A client requests a set of commands to be Presented as part of a future Scenic frame. A single Scenic frame can have multiple client "Presents", where each Present represents a Session's update to the global scene graph. This doc describes the architecture internal to Scenic for how a request becomes pixels.
The diagram below shows the steps a client Present follows when it is requested. Everything between the Scenic FIDL Boundary and the Vulkan driver is currently single-threaded and executes sequentially.
Enqueue()s a set of commands to change the contents of its part of the scene, and calls
Present2()to commit them.
scenic_impl::Sessionwaits for any acquire fences to signal, as well as any previous
Present2()calls whose fences haven't been reached yet.
scenic_impl::Sessionthen schedules an update for the targeted
FrameSchedulerstarts sleeps until there's just enough time to prepare a frame in time for the targeted presentation time. At that point the
FrameSchedulerwakes up and calls
- For each client Session,
ApplyScheduledUpdates(), which applies the commands to the scene graph which were enqueued in step 1. Note:
- Commands from a Session are applied to the global scene graph. The scene graph is in an inconsistent state ("dirty") at this time, and should not be read by other systems (i.e. input) until after the scene graph has been post-processed.
- When all
SessionUpdatershave successfully updated, the
FrameScheduleris notified that the scene graph is dirty, and triggers a
RenderFrame()call on the
- To draw a frame,
gfx::Engine's renderer traverses the scene graph and creates
Escher::objectsfor each element in the scene. The renderer then passes these objects to
Escher, and calls
Escherinterprets the scene graph objects as
vk::commands, and sends these commands to the GPU.
- The GPU processes the commands and sends the results to the display driver.
- The display driver pushes the pixels to the screen.