pub enum SessionRequest {
    Enqueue {
        cmds: Vec<Command>,
        control_handle: SessionControlHandle,
    },
    Present {
        presentation_time: u64,
        acquire_fences: Vec<Event>,
        release_fences: Vec<Event>,
        responder: SessionPresentResponder,
    },
    Present2 {
        args: Present2Args,
        responder: SessionPresent2Responder,
    },
    RequestPresentationTimes {
        requested_prediction_span: i64,
        responder: SessionRequestPresentationTimesResponder,
    },
    RegisterBufferCollection {
        buffer_id: u32,
        token: ClientEnd<BufferCollectionTokenMarker>,
        control_handle: SessionControlHandle,
    },
    DeregisterBufferCollection {
        buffer_id: u32,
        control_handle: SessionControlHandle,
    },
    SetDebugName {
        debug_name: String,
        control_handle: SessionControlHandle,
    },
}
Expand description

Client use Sessions to interact with a Scenic instance by enqueuing commands that create or modify resources.

Variants§

§

Enqueue

Fields

§cmds: Vec<Command>
§control_handle: SessionControlHandle
§

Present

Fields

§presentation_time: u64
§acquire_fences: Vec<Event>
§release_fences: Vec<Event>

Present all previously enqueued operations. In order to pipeline the preparation of the resources required to render the scene, two lists of fences (implemented as events) are passed.

SCHEDULING PRESENTATION

presentation_time specifies the time on or after which the client would like the enqueued operations should take visible effect (light up pixels on the screen), expressed in nanoseconds in the CLOCK_MONOTONIC timebase. Desired presentation times must be monotonically non-decreasing.

Using a desired presentation time in the present or past (such as 0) schedules enqueued operations to take visible effect as soon as possible (during the next frame to be prepared).

Using a desired presentation time in the future schedules the enqueued operations to take visible effect as closely as possible to or after the stated time (but no earlier).

Each rendered frame has a target presentation time. Before rendering a frame, the scene manager applies all enqueued operations associated with all prior calls to Present() whose desired presentation time is on or before the frame’s target presentation time.

The Present() method does not return until the scene manager begins preparing the first frame which includes its presented content. Upon return, the PresentationInfo provides timing information for the frame which includes the presented content.

To present new content on each successive frame, wait for Present() to return before calling Present() again with content for the next frame.

It is also possible to enqueue and present successive frames of content all at once with increasing desired presentation times, incrementing by PresentationInfo.presentation_interval for each one.

Animation updates are also coordinated in terms of presentation time.

SYNCHRONIZATION

acquire_fences are used by Scenic to wait until all of the session’s resources are ready to render (or to allow downstream components, such as the Vulkan driver, to wait for these resources).

For example, Fuchsia’s Vulkan driver allows an zx::event to be obtained from a VkSemaphore. This allows a Scenic client to submit a Vulkan command buffer to generate images/meshes/etc., and instructing Vulkan to signal a VkSemaphore when it is done. By inserting the zx::event corresponding to this semaphore into acquire_fences, the client allows Scenic to submit work to the Vulkan driver without waiting on the CPU for the event to be signalled.

release_fences is a list of events that will be signalled by Scenic when the updated session state has been fully committed: future frames will be rendered using this state, and all frames generated using previous session states have been fully-rendered and presented to the display.

Together, acquire_fences and release_fences are intended to allow clients to implement strategies such as double-buffering. For example, a client might do the following in the Scenic subsystem:

  1. create two Image with resource IDs #1 and #2.
  2. create two Materials with resource IDs #3 and #4, which respectively use Images #1 and #2 as their texture.
  3. create a tree of Nodes and attach them to the scene.
  4. set one of the nodes above, say #5, to use Material #3.
  5. submit a Vulkan command-buffer which renders into Image #1, and will signal a VkSemaphore.
  6. call Present() with one acquire-fence (obtained from the VkSemaphore above) and one newly-created release-fence.

After the steps above, Scenic will use the committed session state to render frames whenever necessary. When the client wants to display something different than Image #1, it would do something similar to steps 4) to 6): 7) set Node #5 to use Material #4. 8) submit a Vulkan command-buffer which renders into Image #1, and will signal a VkSemaphore. 9) call Present() with one acquire-fence (obtained from the VkSemaphore above) and one newly-created release-fence.

Finally, to continually draw new content, the client could repeat steps 4) to 9), with one important difference: step 5) must wait on the event signalled by step 9). Otherwise, it might render into Image #1 while that image is still being used by Scenic to render a frame. Similarly, step 8) must wait on the event signalled by step 6).

The scenario described above uses one acquire-fence and one release-fence, but it is easy to imagine cases that require more. For example, in addition to using Vulkan to render into Images #1 and #2, the client might also upload other resources to Vulkan on a different VkQueue, which would would signal a separate semaphore, and therefore require an additional acquire-fence.

Note: acquire_fences and release_fences are only necessary to synchronize access to memory (and other external resources). Any modification to resources made via the Session API are automatically synchronized.

§

Present2

Present all previously enqueued operations. In order to pipeline the preparation of the resources required to render the scene, two lists of fences, implemented as events, are passed.

When a client calls Present2, they receive an immediate callback consisting of the same information they would get as if they had called RequestPresentationTimes with the equivalent requested_prediction_span. See its documentation below for more information, as Present2’s functionality is a superset of it.

Then, when the commands flushed by Present2 make it to display, an OnFramePresented event is fired. This event includes information pertaining to all Present2s that had content that were part of that frame.

Clients may only use one of Present/Present2 per Session. Switching between both is an error that will result in the Session being closed.

See Present2Args documentation above for more detailed information on what arguments are passed in and their role.

§

RequestPresentationTimes

Fields

§requested_prediction_span: i64

Returns information about future presentation times, and their respective latch points. Clients can use the returned information to make informed scheduling decisions: if a client wants their frame to be displayed at a given presentation_time, they should aim to have all acquire_fences fired before the associated latch_point.

Scenic will attempt to return predictions that span a duration equal to requested_prediction_span, up to a limit.

A value of 0 is guaranteed to give at least one future presentation info.

§

RegisterBufferCollection

Fields

§buffer_id: u32
§control_handle: SessionControlHandle

Registers BufferCollection referenced by the token and sets contraints on it. It does not block on the buffers being allocated until content backed by one of the collection’s VMOs is created, e.g. an Image2.

A value of 0 for the buffer_id is invalid. All other values are valid as long as they are not currently in use.

§

DeregisterBufferCollection

Fields

§buffer_id: u32
§control_handle: SessionControlHandle

Deregisters the BufferCollection previously registered with the buffer_id and sets it to be garbage collected as soon as it is no longer referenced by any resources.

Only buffer_id that have been previously registered and not yet deregistered are valid.

§

SetDebugName

Fields

§debug_name: String
§control_handle: SessionControlHandle

Set an optional debug name for the session. The debug name will be output in things such as logging and trace events.

Implementations§

Trait Implementations§

source§

impl Debug for SessionRequest

source§

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter. Read more

Auto Trait Implementations§

Blanket Implementations§

source§

impl<T> Any for T
where T: 'static + ?Sized,

source§

fn type_id(&self) -> TypeId

Gets the TypeId of self. Read more
source§

impl<T> Borrow<T> for T
where T: ?Sized,

source§

fn borrow(&self) -> &T

Immutably borrows from an owned value. Read more
source§

impl<T> BorrowMut<T> for T
where T: ?Sized,

source§

fn borrow_mut(&mut self) -> &mut T

Mutably borrows from an owned value. Read more
§

impl<T> Encode<Ambiguous1> for T

§

unsafe fn encode( self, _encoder: &mut Encoder<'_>, _offset: usize, _depth: Depth ) -> Result<(), Error>

Encodes the object into the encoder’s buffers. Any handles stored in the object are swapped for Handle::INVALID. Read more
§

impl<T> Encode<Ambiguous2> for T

§

unsafe fn encode( self, _encoder: &mut Encoder<'_>, _offset: usize, _depth: Depth ) -> Result<(), Error>

Encodes the object into the encoder’s buffers. Any handles stored in the object are swapped for Handle::INVALID. Read more
source§

impl<T> From<T> for T

source§

fn from(t: T) -> T

Returns the argument unchanged.

§

impl<T> Instrument for T

§

fn instrument(self, span: Span) -> Instrumented<Self>

Instruments this type with the provided [Span], returning an Instrumented wrapper. Read more
§

fn in_current_span(self) -> Instrumented<Self>

Instruments this type with the current Span, returning an Instrumented wrapper. Read more
source§

impl<T, U> Into<U> for T
where U: From<T>,

source§

fn into(self) -> U

Calls U::from(self).

That is, this conversion is whatever the implementation of From<T> for U chooses to do.

§

impl<T> Pointable for T

§

const ALIGN: usize = _

The alignment of pointer.
§

type Init = T

The type for initializers.
§

unsafe fn init(init: <T as Pointable>::Init) -> usize

Initializes a with the given initializer. Read more
§

unsafe fn deref<'a>(ptr: usize) -> &'a T

Dereferences the given pointer. Read more
§

unsafe fn deref_mut<'a>(ptr: usize) -> &'a mut T

Mutably dereferences the given pointer. Read more
§

unsafe fn drop(ptr: usize)

Drops the object pointed to by the given pointer. Read more
source§

impl<T, U> TryFrom<U> for T
where U: Into<T>,

§

type Error = Infallible

The type returned in the event of a conversion error.
source§

fn try_from(value: U) -> Result<T, <T as TryFrom<U>>::Error>

Performs the conversion.
source§

impl<T, U> TryInto<U> for T
where U: TryFrom<T>,

§

type Error = <U as TryFrom<T>>::Error

The type returned in the event of a conversion error.
source§

fn try_into(self) -> Result<U, <U as TryFrom<T>>::Error>

Performs the conversion.
§

impl<T> WithSubscriber for T

§

fn with_subscriber<S>(self, subscriber: S) -> WithDispatch<Self>
where S: Into<Dispatch>,

Attaches the provided Subscriber to this type, returning a [WithDispatch] wrapper. Read more
§

fn with_current_subscriber(self) -> WithDispatch<Self>

Attaches the current default Subscriber to this type, returning a [WithDispatch] wrapper. Read more