class PresentArgs

`requested_presentation_time` specifies the time on or after which the client would like the

enqueued operations to take visible effect (light up pixels on the screen), expressed in

nanoseconds in the `CLOCK_MONOTONIC` timebase.

The default `requested_presentation_time` is 0.

Using a `requested_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 `requested_presentation_time` in the future schedules the enqueued operations to

take visible effect on or as closely as possible after the stated time, but no earlier.

Each rendered frame has a target presentation time. This is when Flatland aims to have the

frame presented to the user. Before rendering a frame, Flatland applies all

enqueued operations associated with all squashable calls to [`Present`] whose

`requested_presentation_time` is on or before the frame's target presentation time.

`requested_presentation_time` specifies the time on or after which the client would like the

enqueued operations to take visible effect (light up pixels on the screen), expressed in

nanoseconds in the `CLOCK_MONOTONIC` timebase.

The default `requested_presentation_time` is 0.

Using a `requested_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 `requested_presentation_time` in the future schedules the enqueued operations to

take visible effect on or as closely as possible after the stated time, but no earlier.

Each rendered frame has a target presentation time. This is when Flatland aims to have the

frame presented to the user. Before rendering a frame, Flatland applies all

enqueued operations associated with all squashable calls to [`Present`] whose

`requested_presentation_time` is on or before the frame's target presentation time.

`requested_presentation_time` specifies the time on or after which the client would like the

enqueued operations to take visible effect (light up pixels on the screen), expressed in

nanoseconds in the `CLOCK_MONOTONIC` timebase.

The default `requested_presentation_time` is 0.

Using a `requested_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 `requested_presentation_time` in the future schedules the enqueued operations to

take visible effect on or as closely as possible after the stated time, but no earlier.

Each rendered frame has a target presentation time. This is when Flatland aims to have the

frame presented to the user. Before rendering a frame, Flatland applies all

enqueued operations associated with all squashable calls to [`Present`] whose

`requested_presentation_time` is on or before the frame's target presentation time.

Flatland will wait until all of a Flatland instance's `acquire_fences` are ready before it

will execute the presented commands. Not signaling `acquire_fences` will block the current

[`Present`] as well as the following ones even if their `acquire_fences` are signaled.

The default `acquire_fences` value is the empty vector.

Flatland will wait until all of a Flatland instance's `acquire_fences` are ready before it

will execute the presented commands. Not signaling `acquire_fences` will block the current

[`Present`] as well as the following ones even if their `acquire_fences` are signaled.

The default `acquire_fences` value is the empty vector.

Flatland will wait until all of a Flatland instance's `acquire_fences` are ready before it

will execute the presented commands. Not signaling `acquire_fences` will block the current

[`Present`] as well as the following ones even if their `acquire_fences` are signaled.

The default `acquire_fences` value is the empty vector.

Flatland will signal all `release_fences` when it is safe to reuse resources which no longer

appear in the local scene graph at the time of the current [`Present`]. At the latest, this

will happen when the local scene graph (checkpointed at this [`Present`]) has been

integrated into the global scene graph, and the global scene has been displayed on screen.

(Under some circumstances, the fences may be signaled earlier, but clients do not need to

worry about this: the fences will only be signaled when it is safe to reuse the associated

resources).

These fences are intended to manage the reuse of shared memory resources such as sysmem

buffers. For example, it is undesirable for the client to render into an image which is

currently displayed on screen, because this may result in graphical artifacts such as

tearing.

It is up to the client to maintain the mapping between each fence and the resources which

will become reusable when the fence is signaled. A common strategy is to keep track of

resources which were used by the previous [`Present`] but are no longer used by the current

[`Present`]. For example, if an image is removed from the scene by the current [`Present`],

the client would insert a fence here. When the fence is later signaled, the client knows

that it is safe to render into the image and insert it into the local scene graph in a

subsequent [`Present`].

If an error occurs, Flatland may close the channel without signaling these fences. Clients

may immediately release shared buffers, but they should not immediately modify such buffers,

because they may still be displayed on screen. There is currently no good signal available

to the client about when it is safe to reuse shared buffers.

The default `release_fences` value is the empty vector.

Flatland will signal all `release_fences` when it is safe to reuse resources which no longer

appear in the local scene graph at the time of the current [`Present`]. At the latest, this

will happen when the local scene graph (checkpointed at this [`Present`]) has been

integrated into the global scene graph, and the global scene has been displayed on screen.

(Under some circumstances, the fences may be signaled earlier, but clients do not need to

worry about this: the fences will only be signaled when it is safe to reuse the associated

resources).

These fences are intended to manage the reuse of shared memory resources such as sysmem

buffers. For example, it is undesirable for the client to render into an image which is

currently displayed on screen, because this may result in graphical artifacts such as

tearing.

It is up to the client to maintain the mapping between each fence and the resources which

will become reusable when the fence is signaled. A common strategy is to keep track of

resources which were used by the previous [`Present`] but are no longer used by the current

[`Present`]. For example, if an image is removed from the scene by the current [`Present`],

the client would insert a fence here. When the fence is later signaled, the client knows

that it is safe to render into the image and insert it into the local scene graph in a

subsequent [`Present`].

If an error occurs, Flatland may close the channel without signaling these fences. Clients

may immediately release shared buffers, but they should not immediately modify such buffers,

because they may still be displayed on screen. There is currently no good signal available

to the client about when it is safe to reuse shared buffers.

The default `release_fences` value is the empty vector.

Flatland will signal all `release_fences` when it is safe to reuse resources which no longer

appear in the local scene graph at the time of the current [`Present`]. At the latest, this

will happen when the local scene graph (checkpointed at this [`Present`]) has been

integrated into the global scene graph, and the global scene has been displayed on screen.

(Under some circumstances, the fences may be signaled earlier, but clients do not need to

worry about this: the fences will only be signaled when it is safe to reuse the associated

resources).

These fences are intended to manage the reuse of shared memory resources such as sysmem

buffers. For example, it is undesirable for the client to render into an image which is

currently displayed on screen, because this may result in graphical artifacts such as

tearing.

It is up to the client to maintain the mapping between each fence and the resources which

will become reusable when the fence is signaled. A common strategy is to keep track of

resources which were used by the previous [`Present`] but are no longer used by the current

[`Present`]. For example, if an image is removed from the scene by the current [`Present`],

the client would insert a fence here. When the fence is later signaled, the client knows

that it is safe to render into the image and insert it into the local scene graph in a

subsequent [`Present`].

If an error occurs, Flatland may close the channel without signaling these fences. Clients

may immediately release shared buffers, but they should not immediately modify such buffers,

because they may still be displayed on screen. There is currently no good signal available

to the client about when it is safe to reuse shared buffers.

The default `release_fences` value is the empty vector.

If `unsquashable` is true, then the update is guaranteed to be uniquely shown for at

least one vsync interval.

If `unsquashable` is false, then the update can be combined with those that come after

it.

If absent, `unsquashable` is false.

If `unsquashable` is true, then the update is guaranteed to be uniquely shown for at

least one vsync interval.

If `unsquashable` is false, then the update can be combined with those that come after

it.

If absent, `unsquashable` is false.

If `unsquashable` is true, then the update is guaranteed to be uniquely shown for at

least one vsync interval.

If `unsquashable` is false, then the update can be combined with those that come after

it.

If absent, `unsquashable` is false.