class WireWeakSyncClientImpl

Clients should first use the Allocator protocol to register a

BufferCollection. This function will fail with BAD_OPERATION unless all clients of the

BufferCollection have set their constraints.

Afterwards, clients should create and configure the images that will

eventually be rendered to using this method. All the buffers in the

collection from 0 to (buffer_count-1) may be used for screen capture.

Clients are responsible for determining the rotation of the display,

and applying the corrective rotation. For instance, if the display is

mounted 90 degrees clockwise (the "top" is on the right, when looking

at the display), then the client should specify a 270 degree rotation

to account for it.

Similarly, the clients are responsible for specifying a buffer big

enough for the rotated image. If the buffer is too small, a best effort

attempt will be made to render the image.

Finally, clients request the server to render the current screen to the

shared buffers using [`GetNextFrame`].

[`Configure`] can be called again with a new BufferCollectionImportToken

if the client wishes to change any of the configuration settings. In

this case all the buffers from the previous call to [`Configure`] will

be released.

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

Following a successful call to [`Configure`], clients can call

GetNextFrame. This will populate a buffer with the most recent frame.

Clients should wait on the zx::event they pass for successful

completion of the screenshot. It is not guaranteed that the screenshot

will be completed by the time this function returns.

The requested image will be in the BufferCollection that the client set

up in the VMO at the index specified by buffer_id.

When ScreenCapture is used to provide a stream, the rate that the

client calls GetNextFrame will drive the frame rate.

Errors:

BAD_OPERATION if Configure was not called, or not called successfully

MISSING_ARGS if a required argument is not present

BUFFER_FULL if all buffers in the BufferCollection are in use. In this case, ReleaseFrame

must be called to make a buffer available before this function can be called successfully.

Allocates 40 bytes of request buffer on the stack. Response is heap-allocated.

Once the client no longer needs an image, they can call ReleaseFrame on

the VMO index of the buffer so that the server can reuse it in the future.

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