class WireSyncClientImpl

Adds a BufferCollection resource to the image pipe.

The producer is expected to set constraints on this resource for images added

via `AddImage()`. The consumer can set its constraints on

`buffer_collection_token` before or after. Note that the buffers won't be

allocated until all BufferCollectionToken instances are used to set

constraints, on both the producer and consumer side. See collection.fidl for

details.

The following errors will cause the connection to be closed:

- `buffer_collection_id` is already registered

Allocates 40 bytes of message buffer on the stack. No heap allocation necessary.

Allocates 40 bytes of message buffer on the stack. No heap allocation necessary.

Adds an image resource to image pipe.

`buffer_collection_id` refers to the BufferCollectionToken instance that is

registered via `AddBufferCollection()`. The underlying memory objects allocated

are used to address to the image data. `buffer_collection_index` refers to the

index of the memory object allocated in BufferCollection.

`image_format` specifiies image properties. `coded_width` and `coded_height` are

used to set image dimensions.

It is valid to create multiple images backed by the same memory object; they

may even overlap. Consumers must detect this and handle it accordingly.

The following errors will cause the connection to be closed:

- `image_id` is already registered

- `buffer_collection_id` refers to an unregistered BufferCollection.

- `buffer_collection_index` points to a resource index out of the initialized

BufferCollection bounds

- No resource is allocated in the registered BufferCollection.

Allocates 104 bytes of message buffer on the stack. No heap allocation necessary.

Removes a BufferCollection resource from the pipe.

The `buffer_collection_id` resource is detached as well as all Images that are

associated with that BufferCollection. Leads to the same results as calling

`RemoveImage()` on all Images for `buffer_collection_id`.

The producer must wait for all release fences associated with the Images to

be signaled before freeing or modifying the underlying memory object since

the image may still be in use in the presentation queue.

The following errors will cause the connection to be closed:

- `buffer_collection_id` does not reference a currently registered BufferCollection

Allocates 40 bytes of message buffer on the stack. No heap allocation necessary.

Removes an image resource from the pipe.

The `image_id` is detached from the image resource and is free to be

reused to add a new image resource.

Removing an image from the image pipe does not affect the presentation

queue or the currently presented image.

The producer must wait for all release fences associated with the image to

be signaled before freeing or modifying the underlying memory object since

the image may still be in use in the presentation queue.

The following errors will cause the connection to be closed:

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

Allocates 40 bytes of message buffer on the stack. No heap allocation necessary.

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 224 bytes of message buffer on the stack. No heap allocation necessary.