template <>

class WireWeakAsyncClientImpl

Defined at line 1190 of file fidling/gen/sdk/fidl/fuchsia.images/fuchsia.images/cpp/fidl/fuchsia.images/cpp/wire_messaging.h

Public Methods

::fidl::internal::WireThenable< ::fuchsia_images::ImagePipe2::PresentImage> PresentImage (uint32_t image_id, uint64_t presentation_time, ::fidl::VectorView< ::zx::event> acquire_fences, ::fidl::VectorView< ::zx::event> release_fences)

Enqueues the specified image for presentation by the consumer.

The `acquire_fences` are a set of fences which must all be signaled by

the producer before the consumer presents the image.

The `release_fences` are a set of fences which inform the producer that

it's safe to free or modify the `image_id` image, and it's safe to

re-use the fences in `acquire_fences`. The consumer must signal all the

fences in `release_fences` after `image_id` is no longer being

presented. The producer may reuse resources after any of the

`release_fences` is signaled.

This design allows a producer to distribute image processing across

multiple threads / processes without unnecessary coordination delay.

Each thread / process signals its own fence in `acquire_fences` when

it's done rendering its piece of `image_id`, and waits on its own fence

in `release_fences` to render new content in `image_id`.

`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.

`presentation_info` returns timing information about the submitted frame

and future frames (see presentation_info.fidl).

The producer may decide not to signal `acquire_fences` for an image.

In that case, if a later image is enqueued and later image's

`presentation_time` is reached, the consumer presents the later image when

later image's `acquire_fences` are signaled. The consumer also signals

earlier image's `release_fences` and removes it from the presentation queue.

This sequence works as a cancellation mechanism.

The following errors will cause the connection to be closed:

- `image_id` does not reference a currently registered image resource

Allocates 192 bytes of request buffer on the stack. The callback is stored on the heap.