class WireTableBuilder

Vendor-specific pixel format modifier. See format_modifier.fidl.

Vendor-specific pixel format modifier. See format_modifier.fidl.

The size of the image in pixels.

See also `bytes_per_row` which is also necessary (along with `size`) to

find where each pixel's data is within a buffer.

Not all of the addressable pixel positions in the buffer are necessarily

populated with valid pixel data. See `valid_size` for the

potentially-smaller rectangle of valid pixels.

The right and bottom of the image may have some valid pixels which are

not to be displayed. See `display_rect`.

The size of the image in pixels.

See also `bytes_per_row` which is also necessary (along with `size`) to

find where each pixel's data is within a buffer.

Not all of the addressable pixel positions in the buffer are necessarily

populated with valid pixel data. See `valid_size` for the

potentially-smaller rectangle of valid pixels.

The right and bottom of the image may have some valid pixels which are

not to be displayed. See `display_rect`.

The rect within a frame that's for display. This is the location and

size in pixels of the rectangle of pixels that should be displayed, when

displaying the "whole image" in a UI display sense.

The `x` + `width` must be

<

= `size.width`, and the `y` + `height` must

be

<

= `size.height`.

For output from a video decoder, pixels outside the display_rect are

never to be displayed (outside of test programs), but must be preserved

for correct decoder function. The `display_rect` will always fall

within the rect starting at (0, 0) and having `valid_size` size, when

`valid_size` is set. In other words, `display_rect` is a subset (not

necessarily a proper subset) of `valid_size`, and `valid_size` is a

subset (not necessarily a proper subset) of `size`.

Downstream texture filtering operations should avoid letting any pixel

outside of display_rect influence the visual appearance of any displayed

pixel, to avoid the potential for the right or bottom edge leaking in

arbitrary pixels defined by the decode process but not intended for

display.

Behavior when this field is not set is protocol-specific. In some

protocols, fallback to `valid_size`, then to `size` may be implemented.

In others, fallback directly to `size` may be implemented. In others,

this field must be set or the channel will close.

WARNING: fuchsia.sysmem.Images2 (V1) doesn't handle non-zero x, y, so

any non-zero x, y here (V2) will prevent conversion to V1. Due to the

rarity of non-zero x, y in practice, even components that have moved to

V2 may in some cases still assume both x and y are 0, until there's a

practical reason to implment and test handling of non-zero x, y. The

symptom of sending non-zero x, y to a downstream render and/or display

pipeline that assumes 0, 0 will be incorrect display, but not a crash,

since assuming 0, 0 for x, y does not cause reading out of buffer

bounds.

The rect within a frame that's for display. This is the location and

size in pixels of the rectangle of pixels that should be displayed, when

displaying the "whole image" in a UI display sense.

The `x` + `width` must be

<

= `size.width`, and the `y` + `height` must

be

<

= `size.height`.

For output from a video decoder, pixels outside the display_rect are

never to be displayed (outside of test programs), but must be preserved

for correct decoder function. The `display_rect` will always fall

within the rect starting at (0, 0) and having `valid_size` size, when

`valid_size` is set. In other words, `display_rect` is a subset (not

necessarily a proper subset) of `valid_size`, and `valid_size` is a

subset (not necessarily a proper subset) of `size`.

Downstream texture filtering operations should avoid letting any pixel

outside of display_rect influence the visual appearance of any displayed

pixel, to avoid the potential for the right or bottom edge leaking in

arbitrary pixels defined by the decode process but not intended for

display.

Behavior when this field is not set is protocol-specific. In some

protocols, fallback to `valid_size`, then to `size` may be implemented.

In others, fallback directly to `size` may be implemented. In others,

this field must be set or the channel will close.

WARNING: fuchsia.sysmem.Images2 (V1) doesn't handle non-zero x, y, so

any non-zero x, y here (V2) will prevent conversion to V1. Due to the

rarity of non-zero x, y in practice, even components that have moved to

V2 may in some cases still assume both x and y are 0, until there's a

practical reason to implment and test handling of non-zero x, y. The

symptom of sending non-zero x, y to a downstream render and/or display

pipeline that assumes 0, 0 will be incorrect display, but not a crash,

since assuming 0, 0 for x, y does not cause reading out of buffer

bounds.

The size of a frame in terms of the number of pixels that have valid

pixel data in terms of video decoding, but not in terms of which pixels

are intended for display.

To convert valid_size into a rect that's directly comparable to

`display_rect`, one can make a rect with (`x`: 0, `y`: 0, `width`:

`valid_size.width`, `height`: `valid_size.height`).

In the case of a video decoder, `valid_size` can include some pixels

outside `display_rect`. The extra pixels are not meant to be displayed,

and may or may not contain any real image data. Typically anything that

looks like real image data in these regions is only an artifact of video

compression and the existence of the remainder of a macroblock which can

be referenced by later frames despite not being within the displayed

region, and not really any additional "real" pixels from the source. The

pixel values in this region are defined by the codec decode process and

must be retained for correct decoder operation. Typically the pixels

inside valid_size but outside display_rect will be up to the size of a

macroblock minus 1. The `valid_size` is can be useful for testing video

decoders and for certain transcoding scenarios.

The size of a frame in terms of the number of pixels that have valid

pixel data in terms of video decoding, but not in terms of which pixels

are intended for display.

To convert valid_size into a rect that's directly comparable to

`display_rect`, one can make a rect with (`x`: 0, `y`: 0, `width`:

`valid_size.width`, `height`: `valid_size.height`).

In the case of a video decoder, `valid_size` can include some pixels

outside `display_rect`. The extra pixels are not meant to be displayed,

and may or may not contain any real image data. Typically anything that

looks like real image data in these regions is only an artifact of video

compression and the existence of the remainder of a macroblock which can

be referenced by later frames despite not being within the displayed

region, and not really any additional "real" pixels from the source. The

pixel values in this region are defined by the codec decode process and

must be retained for correct decoder operation. Typically the pixels

inside valid_size but outside display_rect will be up to the size of a

macroblock minus 1. The `valid_size` is can be useful for testing video

decoders and for certain transcoding scenarios.

Aspect ratio of a single pixel as the video is intended to be displayed.

For YUV formats, this is the pixel aspect ratio (AKA sample aspect ratio

aka SAR) for the luma (AKA Y) samples.

Producers should ensure the width and height values are relatively prime

by reducing the fraction (dividing both by GCF) if necessary.

A consumer should interpret this field being un-set as an unknown pixel

aspect ratio. A default of 1:1 can be appropriate in some cases, but a

consumer may determine the actual pixel aspect ratio by OOB means.

Aspect ratio of a single pixel as the video is intended to be displayed.

For YUV formats, this is the pixel aspect ratio (AKA sample aspect ratio

aka SAR) for the luma (AKA Y) samples.

Producers should ensure the width and height values are relatively prime

by reducing the fraction (dividing both by GCF) if necessary.

A consumer should interpret this field being un-set as an unknown pixel

aspect ratio. A default of 1:1 can be appropriate in some cases, but a

consumer may determine the actual pixel aspect ratio by OOB means.