class ScanlineOrder

The order in which rows are output from the scanline decoder is not the same for all variations of all image types. This explains the possible output row orderings.


kKeep :

By far the most common, this indicates that the image can be decoded reliably using the scanline decoder, and that rows will be output in the logical order.

kRestoreBGColor :

This indicates that the scanline decoder reliably outputs rows, but they will be returned in reverse order. If the scanline format is kBottomUp, the nextScanline() API can be used to determine the actual y-coordinate of the next output row, but the client is not forced to take advantage of this, given that it’s not too tough to keep track independently.

For full image decodes, it is safe to get all of the scanlines at once, since the decoder will handle inverting the rows as it decodes.

For subset decodes and sampling, it is simplest to get and skip scanlines one at a time, using the nextScanline() API. It is possible to ask for larger chunks at a time, but this should be used with caution. As with full image decodes, the decoder will handle inverting the requested rows, but rows will still be delivered starting from the bottom of the image.

Upside down bmps are an example.



__init__(self: skia.Codec.ScanlineOrder, value: int) -> None







ScanlineOrder.__init__(self: skia.Codec.ScanlineOrder, value: int) None

__init__(self: skia.Codec.ScanlineOrder, value: int) -> None


ScanlineOrder.kKeep = <ScanlineOrder.kKeep: 0>
ScanlineOrder.kRestoreBGColor = <ScanlineOrder.kRestoreBGColor: 1>