Proposal for SkImageGenerator::canDecodeAndScale API

Proposal for SkImageGenerator::canDecodeAndScale API

targetted use:
1) decode images to resolution close to displayed
2) when decoder supports it, decode opaque images to RGB565

BUG=skia:

[aleksandar.stojiljkovic, 2015-10-15 16:10:12]

This is proposal extending original from
https://codereview.chromium.org/1396323007/

[scroggo, 2015-10-15 16:26:32]

scroggo@google.com changed reviewers:
+ scroggo@google.com

[scroggo, 2015-10-15 16:26:33]

https://codereview.chromium.org/1404923004/diff/1/include/core/SkImageGenerat...
File include/core/SkImageGenerator.h (right):

https://codereview.chromium.org/1404923004/diff/1/include/core/SkImageGenerat...
include/core/SkImageGenerator.h:137: bool canDecodeAndScale(const SkColorType
colorType, const SkScalar scale = SK_Scalar1,
Should this also specify an alpha type? Or should we just assume e.g. that the
caller wants opaque for 565?

https://codereview.chromium.org/1404923004/diff/1/include/core/SkImageGenerat...
include/core/SkImageGenerator.h:138: SkISize *availableSize = nullptr, SkISize
*lowerSize = nullptr);
I like that the sizes are named to distinguish what they mean (instead of using
an array of sizes in the other CL).

[aleksandar.stojiljkovic, 2015-10-15 17:00:48]

>
https://codereview.chromium.org/1404923004/diff/1/include/core/SkImageGenerat...
> include/core/SkImageGenerator.h:137: bool canDecodeAndScale(const SkColorType
> colorType, const SkScalar scale = SK_Scalar1,
> Should this also specify an alpha type? Or should we just assume e.g. that the
> caller wants opaque for 565?

Didn't see the usage for specifying alpha type or color profile.

Had doubts too whether the API should be like this:
bool canDecodeAndScale(const SkImageInfo &info, SkISize *availableSize =
nullptr, SkISize *lowerSize = nullptr)
Since it would correspond to implicit usage of info within bool getPixels(const
SkImageInfo& info ... ) to specify different scale. 
But, for different aspect ratios it looks complicated.

For alpha, might be better to delegate SkImageDecoder::getInfo() to subclasses -
as it could change: e.g. in JPEGImageDecoder in chromium, initially set to
hasAlpha (before all data is available and decoded), and once the data is
completely decoded (changing it to fully available) it is set to opaque.

[aleksandar.stojiljkovic, 2015-10-19 15:26:47]

aleksandar.stojiljkovic@intel.com changed reviewers:
+ reed@google.com

[aleksandar.stojiljkovic, 2015-10-19 15:26:48]

Related change: implementation for the proposed API - RGB565 support in Webkit
decoders is in https://codereview.chromium.org/1403393004/

[aleksandar.stojiljkovic, 2015-10-23 09:11:00]

Fixing the review issues.
Corresponding skia change:
Issue 1412423008: Handling large jpegs in CPU raster - downsample to display res
and 565

[aleksandar.stojiljkovic, 2015-10-23 09:37:02]

updated to correspond to state in https://codereview.chromium.org/1412423008
Duplicated here - FWIW API will anyway change as reed is defining it.

https://codereview.chromium.org/1404923004/diff/20001/include/core/SkImageGen...
File include/core/SkImageGenerator.h (right):

https://codereview.chromium.org/1404923004/diff/20001/include/core/SkImageGen...
include/core/SkImageGenerator.h:16: class GrTexture;
Rebased meanwhile...