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.