2015-03-25 18:11:52 +00:00
|
|
|
/*
|
|
|
|
* Copyright 2015 Google Inc.
|
|
|
|
*
|
|
|
|
* Use of this source code is governed by a BSD-style license that can be
|
|
|
|
* found in the LICENSE file.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef SkScanlineDecoder_DEFINED
|
|
|
|
#define SkScanlineDecoder_DEFINED
|
|
|
|
|
2015-08-19 18:56:48 +00:00
|
|
|
#include "../private/SkTemplates.h"
|
SkCodec no longer inherits from SkImageGenerator.
SkImageGenerator makes some assumptions that are not necessarily valid
for SkCodec. For example, SkCodec does not assume that it can always be
rewound.
We also have an ongoing question of what an SkCodec should report as
its default settings (i.e. the return from getInfo). It makes sense for
an SkCodec to report that its pixels are unpremultiplied, if that is
the case for the underlying data, but if a client of SkImageGenerator
uses the default settings (as many do), they will receive
unpremultiplied pixels which cannot (currently) be drawn with Skia. We
may ultimately decide to revisit SkCodec reporting an SkImageInfo, but
I have left it unchanged for now.
Import features of SkImageGenerator used by SkCodec into SkCodec.
I have left SkImageGenerator unchanged for now, but it no longer needs
Result or Options. This will require changes to Chromium.
Manually handle the lifetime of fScanlineDecoder, so SkScanlineDecoder.h
can include SkCodec.h (where Result is), and SkCodec.h does not need
to include it (to delete fScanlineDecoder).
In many places, make the following simple changes:
- Now include SkScanlineDecoder.h, which is no longer included by
SkCodec.h
- Use the enums in SkCodec, rather than SkImageGenerator
- Stop including SkImageGenerator.h where no longer needed
Review URL: https://codereview.chromium.org/1220733013
2015-07-09 15:16:03 +00:00
|
|
|
#include "SkCodec.h"
|
2015-03-25 18:11:52 +00:00
|
|
|
#include "SkImageInfo.h"
|
2015-08-19 18:56:48 +00:00
|
|
|
#include "SkTypes.h"
|
2015-03-25 18:11:52 +00:00
|
|
|
|
|
|
|
class SkScanlineDecoder : public SkNoncopyable {
|
|
|
|
public:
|
2015-08-04 16:24:45 +00:00
|
|
|
/**
|
|
|
|
* If this stream represents an encoded image that we know how to decode
|
|
|
|
* in scanlines, return an SkScanlineDecoder that can decode it. Otherwise
|
|
|
|
* return NULL.
|
|
|
|
*
|
|
|
|
* start() must be called in order to decode any scanlines.
|
|
|
|
*
|
|
|
|
* If NULL is returned, the stream is deleted immediately. Otherwise, the
|
|
|
|
* SkScanlineDecoder takes ownership of it, and will delete it when done
|
|
|
|
* with it.
|
|
|
|
*/
|
|
|
|
static SkScanlineDecoder* NewFromStream(SkStream*);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Similar to NewFromStream, but reads from an SkData.
|
|
|
|
*
|
|
|
|
* Will take a ref if it returns a scanline decoder, else will not affect
|
|
|
|
* the data.
|
|
|
|
*/
|
|
|
|
static SkScanlineDecoder* NewFromData(SkData*);
|
|
|
|
|
2015-07-01 13:50:35 +00:00
|
|
|
/**
|
|
|
|
* Clean up after reading/skipping scanlines.
|
|
|
|
*
|
|
|
|
* It is possible that not all scanlines will have been read/skipped. In
|
|
|
|
* fact, in the case of subset decodes, it is likely that there will be
|
|
|
|
* scanlines at the bottom of the image that have been ignored.
|
|
|
|
*/
|
2015-03-25 18:11:52 +00:00
|
|
|
virtual ~SkScanlineDecoder() {}
|
|
|
|
|
2015-08-14 14:44:46 +00:00
|
|
|
/**
|
|
|
|
* Return a size that approximately supports the desired scale factor.
|
|
|
|
* The codec may not be able to scale efficiently to the exact scale
|
|
|
|
* factor requested, so return a size that approximates that scale.
|
|
|
|
* The returned value is the codec's suggestion for the closest valid
|
|
|
|
* scale that it can natively support
|
|
|
|
* FIXME: share this with SkCodec
|
|
|
|
*/
|
|
|
|
SkISize getScaledDimensions(float desiredScale) {
|
|
|
|
return this->onGetScaledDimensions(desiredScale);
|
|
|
|
}
|
|
|
|
|
2015-08-04 16:24:45 +00:00
|
|
|
/**
|
|
|
|
* Returns the default info, corresponding to the encoded data.
|
|
|
|
*/
|
|
|
|
const SkImageInfo& getInfo() { return fSrcInfo; }
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Initialize on the first scanline, with the specified options.
|
|
|
|
*
|
|
|
|
* This must be called in order to call getScanlnies or skipScanlines. If
|
|
|
|
* it has been called before, this will require rewinding the stream.
|
|
|
|
*
|
|
|
|
* @param dstInfo Info of the destination. If the dimensions do not match
|
|
|
|
* those of getInfo, this implies a scale.
|
|
|
|
* @param options Contains decoding options, including if memory is zero
|
|
|
|
* initialized.
|
|
|
|
* @param ctable A pointer to a color table. When dstInfo.colorType() is
|
|
|
|
* kIndex8, this should be non-NULL and have enough storage for 256
|
|
|
|
* colors. The color table will be populated after decoding the palette.
|
|
|
|
* @param ctableCount A pointer to the size of the color table. When
|
|
|
|
* dstInfo.colorType() is kIndex8, this should be non-NULL. It will
|
|
|
|
* be modified to the true size of the color table (<= 256) after
|
|
|
|
* decoding the palette.
|
|
|
|
* @return Enum representing success or reason for failure.
|
|
|
|
*/
|
|
|
|
SkCodec::Result start(const SkImageInfo& dstInfo, const SkCodec::Options* options,
|
|
|
|
SkPMColor ctable[], int* ctableCount);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Simplified version of start() that asserts that info is NOT
|
|
|
|
* kIndex8_SkColorType and uses the default Options.
|
|
|
|
*/
|
|
|
|
SkCodec::Result start(const SkImageInfo& dstInfo);
|
|
|
|
|
2015-03-25 18:11:52 +00:00
|
|
|
/**
|
|
|
|
* Write the next countLines scanlines into dst.
|
|
|
|
*
|
2015-08-04 16:24:45 +00:00
|
|
|
* Not valid to call before calling start().
|
|
|
|
*
|
2015-03-25 18:11:52 +00:00
|
|
|
* @param dst Must be non-null, and large enough to hold countLines
|
|
|
|
* scanlines of size rowBytes.
|
|
|
|
* @param countLines Number of lines to write.
|
|
|
|
* @param rowBytes Number of bytes per row. Must be large enough to hold
|
|
|
|
* a scanline based on the SkImageInfo used to create this object.
|
|
|
|
*/
|
SkCodec no longer inherits from SkImageGenerator.
SkImageGenerator makes some assumptions that are not necessarily valid
for SkCodec. For example, SkCodec does not assume that it can always be
rewound.
We also have an ongoing question of what an SkCodec should report as
its default settings (i.e. the return from getInfo). It makes sense for
an SkCodec to report that its pixels are unpremultiplied, if that is
the case for the underlying data, but if a client of SkImageGenerator
uses the default settings (as many do), they will receive
unpremultiplied pixels which cannot (currently) be drawn with Skia. We
may ultimately decide to revisit SkCodec reporting an SkImageInfo, but
I have left it unchanged for now.
Import features of SkImageGenerator used by SkCodec into SkCodec.
I have left SkImageGenerator unchanged for now, but it no longer needs
Result or Options. This will require changes to Chromium.
Manually handle the lifetime of fScanlineDecoder, so SkScanlineDecoder.h
can include SkCodec.h (where Result is), and SkCodec.h does not need
to include it (to delete fScanlineDecoder).
In many places, make the following simple changes:
- Now include SkScanlineDecoder.h, which is no longer included by
SkCodec.h
- Use the enums in SkCodec, rather than SkImageGenerator
- Stop including SkImageGenerator.h where no longer needed
Review URL: https://codereview.chromium.org/1220733013
2015-07-09 15:16:03 +00:00
|
|
|
SkCodec::Result getScanlines(void* dst, int countLines, size_t rowBytes) {
|
2015-08-04 16:24:45 +00:00
|
|
|
SkASSERT(!fDstInfo.isEmpty());
|
2015-03-25 18:11:52 +00:00
|
|
|
if ((rowBytes < fDstInfo.minRowBytes() && countLines > 1 ) || countLines <= 0
|
|
|
|
|| fCurrScanline + countLines > fDstInfo.height()) {
|
SkCodec no longer inherits from SkImageGenerator.
SkImageGenerator makes some assumptions that are not necessarily valid
for SkCodec. For example, SkCodec does not assume that it can always be
rewound.
We also have an ongoing question of what an SkCodec should report as
its default settings (i.e. the return from getInfo). It makes sense for
an SkCodec to report that its pixels are unpremultiplied, if that is
the case for the underlying data, but if a client of SkImageGenerator
uses the default settings (as many do), they will receive
unpremultiplied pixels which cannot (currently) be drawn with Skia. We
may ultimately decide to revisit SkCodec reporting an SkImageInfo, but
I have left it unchanged for now.
Import features of SkImageGenerator used by SkCodec into SkCodec.
I have left SkImageGenerator unchanged for now, but it no longer needs
Result or Options. This will require changes to Chromium.
Manually handle the lifetime of fScanlineDecoder, so SkScanlineDecoder.h
can include SkCodec.h (where Result is), and SkCodec.h does not need
to include it (to delete fScanlineDecoder).
In many places, make the following simple changes:
- Now include SkScanlineDecoder.h, which is no longer included by
SkCodec.h
- Use the enums in SkCodec, rather than SkImageGenerator
- Stop including SkImageGenerator.h where no longer needed
Review URL: https://codereview.chromium.org/1220733013
2015-07-09 15:16:03 +00:00
|
|
|
return SkCodec::kInvalidParameters;
|
2015-03-25 18:11:52 +00:00
|
|
|
}
|
SkCodec no longer inherits from SkImageGenerator.
SkImageGenerator makes some assumptions that are not necessarily valid
for SkCodec. For example, SkCodec does not assume that it can always be
rewound.
We also have an ongoing question of what an SkCodec should report as
its default settings (i.e. the return from getInfo). It makes sense for
an SkCodec to report that its pixels are unpremultiplied, if that is
the case for the underlying data, but if a client of SkImageGenerator
uses the default settings (as many do), they will receive
unpremultiplied pixels which cannot (currently) be drawn with Skia. We
may ultimately decide to revisit SkCodec reporting an SkImageInfo, but
I have left it unchanged for now.
Import features of SkImageGenerator used by SkCodec into SkCodec.
I have left SkImageGenerator unchanged for now, but it no longer needs
Result or Options. This will require changes to Chromium.
Manually handle the lifetime of fScanlineDecoder, so SkScanlineDecoder.h
can include SkCodec.h (where Result is), and SkCodec.h does not need
to include it (to delete fScanlineDecoder).
In many places, make the following simple changes:
- Now include SkScanlineDecoder.h, which is no longer included by
SkCodec.h
- Use the enums in SkCodec, rather than SkImageGenerator
- Stop including SkImageGenerator.h where no longer needed
Review URL: https://codereview.chromium.org/1220733013
2015-07-09 15:16:03 +00:00
|
|
|
const SkCodec::Result result = this->onGetScanlines(dst, countLines, rowBytes);
|
2015-07-01 13:50:35 +00:00
|
|
|
fCurrScanline += countLines;
|
2015-03-25 18:11:52 +00:00
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Skip count scanlines.
|
|
|
|
*
|
2015-08-04 16:24:45 +00:00
|
|
|
* Not valid to call before calling start().
|
|
|
|
*
|
2015-03-25 18:11:52 +00:00
|
|
|
* The default version just calls onGetScanlines and discards the dst.
|
|
|
|
* NOTE: If skipped lines are the only lines with alpha, this default
|
|
|
|
* will make reallyHasAlpha return true, when it could have returned
|
|
|
|
* false.
|
|
|
|
*/
|
SkCodec no longer inherits from SkImageGenerator.
SkImageGenerator makes some assumptions that are not necessarily valid
for SkCodec. For example, SkCodec does not assume that it can always be
rewound.
We also have an ongoing question of what an SkCodec should report as
its default settings (i.e. the return from getInfo). It makes sense for
an SkCodec to report that its pixels are unpremultiplied, if that is
the case for the underlying data, but if a client of SkImageGenerator
uses the default settings (as many do), they will receive
unpremultiplied pixels which cannot (currently) be drawn with Skia. We
may ultimately decide to revisit SkCodec reporting an SkImageInfo, but
I have left it unchanged for now.
Import features of SkImageGenerator used by SkCodec into SkCodec.
I have left SkImageGenerator unchanged for now, but it no longer needs
Result or Options. This will require changes to Chromium.
Manually handle the lifetime of fScanlineDecoder, so SkScanlineDecoder.h
can include SkCodec.h (where Result is), and SkCodec.h does not need
to include it (to delete fScanlineDecoder).
In many places, make the following simple changes:
- Now include SkScanlineDecoder.h, which is no longer included by
SkCodec.h
- Use the enums in SkCodec, rather than SkImageGenerator
- Stop including SkImageGenerator.h where no longer needed
Review URL: https://codereview.chromium.org/1220733013
2015-07-09 15:16:03 +00:00
|
|
|
SkCodec::Result skipScanlines(int countLines) {
|
2015-08-04 16:24:45 +00:00
|
|
|
SkASSERT(!fDstInfo.isEmpty());
|
2015-03-25 18:11:52 +00:00
|
|
|
if (fCurrScanline + countLines > fDstInfo.height()) {
|
|
|
|
// Arguably, we could just skip the scanlines which are remaining,
|
|
|
|
// and return kSuccess. We choose to return invalid so the client
|
|
|
|
// can catch their bug.
|
SkCodec no longer inherits from SkImageGenerator.
SkImageGenerator makes some assumptions that are not necessarily valid
for SkCodec. For example, SkCodec does not assume that it can always be
rewound.
We also have an ongoing question of what an SkCodec should report as
its default settings (i.e. the return from getInfo). It makes sense for
an SkCodec to report that its pixels are unpremultiplied, if that is
the case for the underlying data, but if a client of SkImageGenerator
uses the default settings (as many do), they will receive
unpremultiplied pixels which cannot (currently) be drawn with Skia. We
may ultimately decide to revisit SkCodec reporting an SkImageInfo, but
I have left it unchanged for now.
Import features of SkImageGenerator used by SkCodec into SkCodec.
I have left SkImageGenerator unchanged for now, but it no longer needs
Result or Options. This will require changes to Chromium.
Manually handle the lifetime of fScanlineDecoder, so SkScanlineDecoder.h
can include SkCodec.h (where Result is), and SkCodec.h does not need
to include it (to delete fScanlineDecoder).
In many places, make the following simple changes:
- Now include SkScanlineDecoder.h, which is no longer included by
SkCodec.h
- Use the enums in SkCodec, rather than SkImageGenerator
- Stop including SkImageGenerator.h where no longer needed
Review URL: https://codereview.chromium.org/1220733013
2015-07-09 15:16:03 +00:00
|
|
|
return SkCodec::kInvalidParameters;
|
2015-03-25 18:11:52 +00:00
|
|
|
}
|
SkCodec no longer inherits from SkImageGenerator.
SkImageGenerator makes some assumptions that are not necessarily valid
for SkCodec. For example, SkCodec does not assume that it can always be
rewound.
We also have an ongoing question of what an SkCodec should report as
its default settings (i.e. the return from getInfo). It makes sense for
an SkCodec to report that its pixels are unpremultiplied, if that is
the case for the underlying data, but if a client of SkImageGenerator
uses the default settings (as many do), they will receive
unpremultiplied pixels which cannot (currently) be drawn with Skia. We
may ultimately decide to revisit SkCodec reporting an SkImageInfo, but
I have left it unchanged for now.
Import features of SkImageGenerator used by SkCodec into SkCodec.
I have left SkImageGenerator unchanged for now, but it no longer needs
Result or Options. This will require changes to Chromium.
Manually handle the lifetime of fScanlineDecoder, so SkScanlineDecoder.h
can include SkCodec.h (where Result is), and SkCodec.h does not need
to include it (to delete fScanlineDecoder).
In many places, make the following simple changes:
- Now include SkScanlineDecoder.h, which is no longer included by
SkCodec.h
- Use the enums in SkCodec, rather than SkImageGenerator
- Stop including SkImageGenerator.h where no longer needed
Review URL: https://codereview.chromium.org/1220733013
2015-07-09 15:16:03 +00:00
|
|
|
const SkCodec::Result result = this->onSkipScanlines(countLines);
|
2015-07-01 13:50:35 +00:00
|
|
|
fCurrScanline += countLines;
|
2015-03-25 18:11:52 +00:00
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Some images may initially report that they have alpha due to the format
|
|
|
|
* of the encoded data, but then never use any colors which have alpha
|
|
|
|
* less than 100%. This function can be called *after* decoding to
|
|
|
|
* determine if such an image truly had alpha. Calling it before decoding
|
|
|
|
* is undefined.
|
|
|
|
* FIXME: see skbug.com/3582.
|
|
|
|
*/
|
|
|
|
bool reallyHasAlpha() const {
|
|
|
|
return this->onReallyHasAlpha();
|
|
|
|
}
|
|
|
|
|
2015-08-14 14:44:46 +00:00
|
|
|
/**
|
|
|
|
* Format of the encoded data.
|
|
|
|
*/
|
|
|
|
SkEncodedFormat getEncodedFormat() const { return this->onGetEncodedFormat(); }
|
|
|
|
|
|
|
|
/**
|
2015-08-31 13:55:13 +00:00
|
|
|
* 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.
|
|
|
|
*/
|
|
|
|
enum SkScanlineOrder {
|
|
|
|
/*
|
|
|
|
* 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.
|
|
|
|
*/
|
|
|
|
kTopDown_SkScanlineOrder,
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This indicates that the scanline decoder reliably outputs rows, but
|
|
|
|
* they will be returned in reverse order. If the scanline format is
|
|
|
|
* kBottomUp, the getY() 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 getY() 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.
|
|
|
|
*/
|
|
|
|
kBottomUp_SkScanlineOrder,
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This indicates that the scanline decoder reliably outputs rows, but
|
|
|
|
* they will not be in logical order. If the scanline format is
|
|
|
|
* kOutOfOrder, the getY() API should be used to determine the actual
|
|
|
|
* y-coordinate of the next output row.
|
|
|
|
*
|
|
|
|
* For this scanline ordering, it is advisable to get and skip
|
|
|
|
* scanlines one at a time.
|
|
|
|
*
|
|
|
|
* Interlaced gifs are an example.
|
|
|
|
*/
|
|
|
|
kOutOfOrder_SkScanlineOrder,
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Indicates that the entire image must be decoded in order to output
|
|
|
|
* any amount of scanlines. In this case, it is a REALLY BAD IDEA to
|
|
|
|
* request scanlines 1-by-1 or in small chunks. The client should
|
|
|
|
* determine which scanlines are needed and ask for all of them in
|
|
|
|
* a single call to getScanlines().
|
|
|
|
*
|
|
|
|
* Interlaced pngs are an example.
|
|
|
|
*/
|
|
|
|
kNone_SkScanlineOrder,
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* An enum representing the order in which scanlines will be returned by
|
|
|
|
* the scanline decoder.
|
|
|
|
*/
|
|
|
|
SkScanlineOrder getScanlineOrder() const { return this->onGetScanlineOrder(); }
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Returns the y-coordinate of the next row to be returned by the scanline
|
|
|
|
* decoder. This will be overridden in the case of
|
|
|
|
* kOutOfOrder_SkScanlineOrder and should be unnecessary in the case of
|
|
|
|
* kNone_SkScanlineOrder.
|
|
|
|
*/
|
|
|
|
int getY() const {
|
|
|
|
SkASSERT(kNone_SkScanlineOrder != this->getScanlineOrder());
|
|
|
|
return this->onGetY();
|
2015-08-14 14:44:46 +00:00
|
|
|
}
|
|
|
|
|
2015-03-25 18:11:52 +00:00
|
|
|
protected:
|
2015-08-04 16:24:45 +00:00
|
|
|
SkScanlineDecoder(const SkImageInfo& srcInfo)
|
|
|
|
: fSrcInfo(srcInfo)
|
|
|
|
, fDstInfo()
|
2015-08-31 13:55:13 +00:00
|
|
|
, fOptions()
|
2015-03-25 18:11:52 +00:00
|
|
|
, fCurrScanline(0) {}
|
|
|
|
|
2015-08-14 14:44:46 +00:00
|
|
|
virtual SkISize onGetScaledDimensions(float /* desiredScale */) {
|
|
|
|
// By default, scaling is not supported.
|
|
|
|
return this->getInfo().dimensions();
|
|
|
|
}
|
|
|
|
|
|
|
|
virtual SkEncodedFormat onGetEncodedFormat() const = 0;
|
|
|
|
|
2015-03-25 18:11:52 +00:00
|
|
|
virtual bool onReallyHasAlpha() const { return false; }
|
|
|
|
|
2015-08-14 14:44:46 +00:00
|
|
|
/**
|
2015-08-31 13:55:13 +00:00
|
|
|
* Most images types will be kTopDown and will not need to override this function.
|
2015-08-14 14:44:46 +00:00
|
|
|
*/
|
2015-08-31 13:55:13 +00:00
|
|
|
virtual SkScanlineOrder onGetScanlineOrder() const { return kTopDown_SkScanlineOrder; }
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Most images will be kTopDown and will not need to override this function.
|
|
|
|
*/
|
|
|
|
virtual int onGetY() const { return fCurrScanline; }
|
2015-08-14 14:44:46 +00:00
|
|
|
|
2015-04-29 15:17:15 +00:00
|
|
|
const SkImageInfo& dstInfo() const { return fDstInfo; }
|
|
|
|
|
2015-08-31 13:55:13 +00:00
|
|
|
const SkCodec::Options& options() const { return fOptions; }
|
|
|
|
|
2015-03-25 18:11:52 +00:00
|
|
|
private:
|
2015-08-04 16:24:45 +00:00
|
|
|
const SkImageInfo fSrcInfo;
|
|
|
|
SkImageInfo fDstInfo;
|
2015-08-31 13:55:13 +00:00
|
|
|
SkCodec::Options fOptions;
|
2015-03-25 18:11:52 +00:00
|
|
|
int fCurrScanline;
|
|
|
|
|
2015-08-04 16:24:45 +00:00
|
|
|
virtual SkCodec::Result onStart(const SkImageInfo& dstInfo,
|
|
|
|
const SkCodec::Options& options,
|
|
|
|
SkPMColor ctable[], int* ctableCount) = 0;
|
|
|
|
|
2015-03-25 18:11:52 +00:00
|
|
|
// Naive default version just calls onGetScanlines on temp memory.
|
SkCodec no longer inherits from SkImageGenerator.
SkImageGenerator makes some assumptions that are not necessarily valid
for SkCodec. For example, SkCodec does not assume that it can always be
rewound.
We also have an ongoing question of what an SkCodec should report as
its default settings (i.e. the return from getInfo). It makes sense for
an SkCodec to report that its pixels are unpremultiplied, if that is
the case for the underlying data, but if a client of SkImageGenerator
uses the default settings (as many do), they will receive
unpremultiplied pixels which cannot (currently) be drawn with Skia. We
may ultimately decide to revisit SkCodec reporting an SkImageInfo, but
I have left it unchanged for now.
Import features of SkImageGenerator used by SkCodec into SkCodec.
I have left SkImageGenerator unchanged for now, but it no longer needs
Result or Options. This will require changes to Chromium.
Manually handle the lifetime of fScanlineDecoder, so SkScanlineDecoder.h
can include SkCodec.h (where Result is), and SkCodec.h does not need
to include it (to delete fScanlineDecoder).
In many places, make the following simple changes:
- Now include SkScanlineDecoder.h, which is no longer included by
SkCodec.h
- Use the enums in SkCodec, rather than SkImageGenerator
- Stop including SkImageGenerator.h where no longer needed
Review URL: https://codereview.chromium.org/1220733013
2015-07-09 15:16:03 +00:00
|
|
|
virtual SkCodec::Result onSkipScanlines(int countLines) {
|
2015-03-25 18:11:52 +00:00
|
|
|
SkAutoMalloc storage(fDstInfo.minRowBytes());
|
|
|
|
// Note that we pass 0 to rowBytes so we continue to use the same memory.
|
|
|
|
// Also note that while getScanlines checks that rowBytes is big enough,
|
|
|
|
// onGetScanlines bypasses that check.
|
|
|
|
// Calling the virtual method also means we do not double count
|
|
|
|
// countLines.
|
|
|
|
return this->onGetScanlines(storage.get(), countLines, 0);
|
|
|
|
}
|
|
|
|
|
SkCodec no longer inherits from SkImageGenerator.
SkImageGenerator makes some assumptions that are not necessarily valid
for SkCodec. For example, SkCodec does not assume that it can always be
rewound.
We also have an ongoing question of what an SkCodec should report as
its default settings (i.e. the return from getInfo). It makes sense for
an SkCodec to report that its pixels are unpremultiplied, if that is
the case for the underlying data, but if a client of SkImageGenerator
uses the default settings (as many do), they will receive
unpremultiplied pixels which cannot (currently) be drawn with Skia. We
may ultimately decide to revisit SkCodec reporting an SkImageInfo, but
I have left it unchanged for now.
Import features of SkImageGenerator used by SkCodec into SkCodec.
I have left SkImageGenerator unchanged for now, but it no longer needs
Result or Options. This will require changes to Chromium.
Manually handle the lifetime of fScanlineDecoder, so SkScanlineDecoder.h
can include SkCodec.h (where Result is), and SkCodec.h does not need
to include it (to delete fScanlineDecoder).
In many places, make the following simple changes:
- Now include SkScanlineDecoder.h, which is no longer included by
SkCodec.h
- Use the enums in SkCodec, rather than SkImageGenerator
- Stop including SkImageGenerator.h where no longer needed
Review URL: https://codereview.chromium.org/1220733013
2015-07-09 15:16:03 +00:00
|
|
|
virtual SkCodec::Result onGetScanlines(void* dst, int countLines,
|
2015-03-25 18:11:52 +00:00
|
|
|
size_t rowBytes) = 0;
|
|
|
|
|
|
|
|
};
|
|
|
|
#endif // SkScanlineDecoder_DEFINED
|