class BufferCollectionConstraints

Default constructs a |BufferCollectionConstraints| only if all of its members are default constructible.

The usage is only meant as a hint to help sysmem choose a more optimal

PixelFormat or similar when multiple compatible options exist.

When aggregating BufferCollectionConstraints, these values bitwise-OR.

At least one usage bit must be specified unless the whole

BufferCollectionConstraints is logically null due to !has_constraints.

The usage is only meant as a hint to help sysmem choose a more optimal

PixelFormat or similar when multiple compatible options exist.

When aggregating BufferCollectionConstraints, these values bitwise-OR.

At least one usage bit must be specified unless the whole

BufferCollectionConstraints is logically null due to !has_constraints.

The usage is only meant as a hint to help sysmem choose a more optimal

PixelFormat or similar when multiple compatible options exist.

When aggregating BufferCollectionConstraints, these values bitwise-OR.

At least one usage bit must be specified unless the whole

BufferCollectionConstraints is logically null due to !has_constraints.

Per-participant number of buffers that the participant may concurrently

hold for its exclusive use for a non-transient period of time (camp on).

For example, a video decoder would specify (at least) the maximum number

of reference frames + 1 frame currently being decoded into.

A participant must not camp on more buffers than specified here (except

very transiently) else processing may get stuck.

When aggregating BufferCollectionConstraints, these values add.

In testing scenarios, camping on more buffers than this for any

significant duration may (ideally will) be flagged as a failure. In

testing scenarios, the participant may not be provided with more buffers

than this concurrently.

Per-participant number of buffers that the participant may concurrently

hold for its exclusive use for a non-transient period of time (camp on).

For example, a video decoder would specify (at least) the maximum number

of reference frames + 1 frame currently being decoded into.

A participant must not camp on more buffers than specified here (except

very transiently) else processing may get stuck.

When aggregating BufferCollectionConstraints, these values add.

In testing scenarios, camping on more buffers than this for any

significant duration may (ideally will) be flagged as a failure. In

testing scenarios, the participant may not be provided with more buffers

than this concurrently.

Per-participant number of buffers that the participant may concurrently

hold for its exclusive use for a non-transient period of time (camp on).

For example, a video decoder would specify (at least) the maximum number

of reference frames + 1 frame currently being decoded into.

A participant must not camp on more buffers than specified here (except

very transiently) else processing may get stuck.

When aggregating BufferCollectionConstraints, these values add.

In testing scenarios, camping on more buffers than this for any

significant duration may (ideally will) be flagged as a failure. In

testing scenarios, the participant may not be provided with more buffers

than this concurrently.

Per-participant minimum number of buffers that are needed for slack

reasons, for better overlap of processing / better performance.

When aggregating BufferCollectionConstraints, these values add.

A participant should typically specify 0 or 1 here - typically 0 is

appropriate if min_buffer_count_for_camping is already enough to keep

the participant busy 100% of the time when the participant is slightly

behind, while 1 can be appropriate if 1 more buffer than strictly needed

for min-camping reasons gives enough slack to stay busy 100% of the time

(when slightly behind, vs. lower % without the extra buffer).

In testing scenarios, this field may be forced to 0, and all

participants are expected to continue to work without getting stuck. If

a buffer is needed for forward progress reasons, that buffer should be

accounted for in min_buffer_count_for_camping.

Per-participant minimum number of buffers that are needed for slack

reasons, for better overlap of processing / better performance.

When aggregating BufferCollectionConstraints, these values add.

A participant should typically specify 0 or 1 here - typically 0 is

appropriate if min_buffer_count_for_camping is already enough to keep

the participant busy 100% of the time when the participant is slightly

behind, while 1 can be appropriate if 1 more buffer than strictly needed

for min-camping reasons gives enough slack to stay busy 100% of the time

(when slightly behind, vs. lower % without the extra buffer).

In testing scenarios, this field may be forced to 0, and all

participants are expected to continue to work without getting stuck. If

a buffer is needed for forward progress reasons, that buffer should be

accounted for in min_buffer_count_for_camping.

Per-participant minimum number of buffers that are needed for slack

reasons, for better overlap of processing / better performance.

When aggregating BufferCollectionConstraints, these values add.

A participant should typically specify 0 or 1 here - typically 0 is

appropriate if min_buffer_count_for_camping is already enough to keep

the participant busy 100% of the time when the participant is slightly

behind, while 1 can be appropriate if 1 more buffer than strictly needed

for min-camping reasons gives enough slack to stay busy 100% of the time

(when slightly behind, vs. lower % without the extra buffer).

In testing scenarios, this field may be forced to 0, and all

participants are expected to continue to work without getting stuck. If

a buffer is needed for forward progress reasons, that buffer should be

accounted for in min_buffer_count_for_camping.

Similar to min_buffer_count_for_dedicated_slack, except when aggregating

these values max (instead of add). The value here is not shared with

any participant's min_buffer_count_for_dedicated_slack.

A participant can specify > 0 here if a participant would like to ensure

there's some slack overall, but doesn't need that slack to be dedicated.

The choice whether to use min_buffer_count_for_dedicated_slack or

min_buffer_count_for_shared_slack (or both) will typically be about the

degree to which the extra slack improves performance.

In testing scenarios, this field may be forced to 0, and all

participants are expected to continue to work without getting stuck. If

a buffer is needed for forward progress reasons, that buffer should be

accounted for in min_buffer_count_for_camping.

Similar to min_buffer_count_for_dedicated_slack, except when aggregating

these values max (instead of add). The value here is not shared with

any participant's min_buffer_count_for_dedicated_slack.

A participant can specify > 0 here if a participant would like to ensure

there's some slack overall, but doesn't need that slack to be dedicated.

The choice whether to use min_buffer_count_for_dedicated_slack or

min_buffer_count_for_shared_slack (or both) will typically be about the

degree to which the extra slack improves performance.

In testing scenarios, this field may be forced to 0, and all

participants are expected to continue to work without getting stuck. If

a buffer is needed for forward progress reasons, that buffer should be

accounted for in min_buffer_count_for_camping.

Similar to min_buffer_count_for_dedicated_slack, except when aggregating

these values max (instead of add). The value here is not shared with

any participant's min_buffer_count_for_dedicated_slack.

A participant can specify > 0 here if a participant would like to ensure

there's some slack overall, but doesn't need that slack to be dedicated.

The choice whether to use min_buffer_count_for_dedicated_slack or

min_buffer_count_for_shared_slack (or both) will typically be about the

degree to which the extra slack improves performance.

In testing scenarios, this field may be forced to 0, and all

participants are expected to continue to work without getting stuck. If

a buffer is needed for forward progress reasons, that buffer should be

accounted for in min_buffer_count_for_camping.

A particularly-picky participant may unfortunately need to demand a

tight range of buffer_count, or even a specific buffer_count. This

field should remain 0 unless a participant really must set this field to

constrain the overall BufferCollectionInfo_2.buffer_count. Any such

participant should still fill out the min_buffer_count_for_* fields

above.

A particularly-picky participant may unfortunately need to demand a

tight range of buffer_count, or even a specific buffer_count. This

field should remain 0 unless a participant really must set this field to

constrain the overall BufferCollectionInfo_2.buffer_count. Any such

participant should still fill out the min_buffer_count_for_* fields

above.

A particularly-picky participant may unfortunately need to demand a

tight range of buffer_count, or even a specific buffer_count. This

field should remain 0 unless a participant really must set this field to

constrain the overall BufferCollectionInfo_2.buffer_count. Any such

participant should still fill out the min_buffer_count_for_* fields

above.

0 is treated as 0xFFFFFFFF.

0 is treated as 0xFFFFFFFF.

0 is treated as 0xFFFFFFFF.

Constraints on BufferCollectionSettings.buffer_settings.

A participant that intends to specify image_format_constraints_count > 1

will typically specify the minimum buffer size implicitly via

image_format_constraints, and possibly specify only the max buffer size

via buffer_memory_constraints.

Constraints on BufferCollectionSettings.buffer_settings.

A participant that intends to specify image_format_constraints_count > 1

will typically specify the minimum buffer size implicitly via

image_format_constraints, and possibly specify only the max buffer size

via buffer_memory_constraints.

Constraints on BufferCollectionSettings.buffer_settings.

A participant that intends to specify image_format_constraints_count > 1

will typically specify the minimum buffer size implicitly via

image_format_constraints, and possibly specify only the max buffer size

via buffer_memory_constraints.

Setter for buffer_memory_constraints.

Optional constraints on the image format parameters of an image stored

in a buffer of the BufferCollection. This includes pixel format and

image layout. These constraints are per-pixel-format, so more than one

is permitted. Entries in the list must have unique pixel_formats.

When aggregating, only pixel formats that are specified by all

participants with non-zero image_format_constraints_count (and non-Null)

BufferCollectionConstraints are retained.

Optional constraints on the image format parameters of an image stored

in a buffer of the BufferCollection. This includes pixel format and

image layout. These constraints are per-pixel-format, so more than one

is permitted. Entries in the list must have unique pixel_formats.

When aggregating, only pixel formats that are specified by all

participants with non-zero image_format_constraints_count (and non-Null)

BufferCollectionConstraints are retained.

Optional constraints on the image format parameters of an image stored

in a buffer of the BufferCollection. This includes pixel format and

image layout. These constraints are per-pixel-format, so more than one

is permitted. Entries in the list must have unique pixel_formats.

When aggregating, only pixel formats that are specified by all

participants with non-zero image_format_constraints_count (and non-Null)

BufferCollectionConstraints are retained.

Setter for image_format_constraints.