SkDecodingImageGenerator now uses SkStreamRewindable

SkDecodingImageGenerator now uses SkStreamRewindable

This makes sense since Android will be giving us a stream and the
decoders expect a stream.  This also removes some glue code,
DecodeMemoryToTarget, that works better using a SkImageGenerator.

Motivation: This is a necessary step to move from SkImageRef to
SkDiscardablePixelRef.

SkImageDecoder::DecodeMemoryToTarget function removed.

BUG=
R=reed@google.com, scroggo@google.com

Committed: https://code.google.com/p/skia/source/detail?r=12560

[bungeman-skia, 2013-12-05 21:03:44]

https://codereview.chromium.org/101973005/diff/1/include/core/SkStream.h
File include/core/SkStream.h (right):

https://codereview.chromium.org/101973005/diff/1/include/core/SkStream.h#newc...
include/core/SkStream.h:133: virtual SkData* getData() const { return NULL; }
I would put this down with SkStreamMemory, replacing the TODO. Generally, these
are put into the section where they start to be required. Putting this in the
SkStreamMemory section does not preclude SkStreamAssets (or any other SkStream
type for that matter) from implementing it (to work all or some of the time).

https://codereview.chromium.org/101973005/diff/1/include/core/SkStream.h#newc...
include/core/SkStream.h:179: virtual const void* getMemoryBase() SK_OVERRIDE =
0;
virtual SkData* getData() const SK_OVERRIDE = 0;

should go here, even if it must be commented out at the moment (which I don't
think it does). This would document that an SkStreamMemory is expected to always
be able to produce an SkData here, and forces implementations to consider the
implementation of this method.

[scroggo, 2013-12-05 21:07:18]

lgtm

https://codereview.chromium.org/101973005/diff/1/include/core/SkData.h
File include/core/SkData.h (right):

https://codereview.chromium.org/101973005/diff/1/include/core/SkData.h#newcode79
include/core/SkData.h:79: *  You probably want to try stream->getData() first.
Can you specify why getData is better?

https://codereview.chromium.org/101973005/diff/1/src/core/SkStream.cpp
File src/core/SkStream.cpp (right):

https://codereview.chromium.org/101973005/diff/1/src/core/SkStream.cpp#newcod...
src/core/SkStream.cpp:353: return SkSafeRef(fData);
Could just use SkRef, since fData cannot be NULL.

https://codereview.chromium.org/101973005/diff/1/src/images/SkDecodingImageGe...
File src/images/SkDecodingImageGenerator.cpp (right):

https://codereview.chromium.org/101973005/diff/1/src/images/SkDecodingImageGe...
src/images/SkDecodingImageGenerator.cpp:106: if (!SkBitmapToImageInfo(bitmap,
&fInfo)) {
Once https://codereview.chromium.org/68973005/ is submitted, can you call
SkBitmap::asImageInfo?

[hal.canary, 2013-12-05 22:29:29]

https://codereview.chromium.org/101973005/diff/1/include/core/SkData.h
File include/core/SkData.h (right):

https://codereview.chromium.org/101973005/diff/1/include/core/SkData.h#newcode79
include/core/SkData.h:79: *  You probably want to try stream->getData() first.
On 2013/12/05 21:07:18, scroggo wrote:
> Can you specify why getData is better?

Done.

https://codereview.chromium.org/101973005/diff/1/include/core/SkStream.h
File include/core/SkStream.h (right):

https://codereview.chromium.org/101973005/diff/1/include/core/SkStream.h#newc...
include/core/SkStream.h:133: virtual SkData* getData() const { return NULL; }
On 2013/12/05 21:03:44, bungeman1 wrote:
> I would put this down with SkStreamMemory, replacing the TODO. Generally,
these
> are put into the section where they start to be required. Putting this in the
> SkStreamMemory section does not preclude SkStreamAssets (or any other SkStream
> type for that matter) from implementing it (to work all or some of the time).

Done.

https://codereview.chromium.org/101973005/diff/1/include/core/SkStream.h#newc...
include/core/SkStream.h:179: virtual const void* getMemoryBase() SK_OVERRIDE =
0;
On 2013/12/05 21:03:44, bungeman1 wrote:
> virtual SkData* getData() const SK_OVERRIDE = 0;
> 
> should go here, even if it must be commented out at the moment (which I don't
> think it does). This would document that an SkStreamMemory is expected to
always
> be able to produce an SkData here, and forces implementations to consider the
> implementation of this method.

Done.

https://codereview.chromium.org/101973005/diff/1/src/core/SkStream.cpp
File src/core/SkStream.cpp (right):

https://codereview.chromium.org/101973005/diff/1/src/core/SkStream.cpp#newcod...
src/core/SkStream.cpp:353: return SkSafeRef(fData);
On 2013/12/05 21:07:18, scroggo wrote:
> Could just use SkRef, since fData cannot be NULL.

Done.  I hadn't seen that template.

https://codereview.chromium.org/101973005/diff/1/src/images/SkDecodingImageGe...
File src/images/SkDecodingImageGenerator.cpp (right):

https://codereview.chromium.org/101973005/diff/1/src/images/SkDecodingImageGe...
src/images/SkDecodingImageGenerator.cpp:106: if (!SkBitmapToImageInfo(bitmap,
&fInfo)) {
On 2013/12/05 21:07:18, scroggo wrote:
> Once https://codereview.chromium.org/68973005/ is submitted, can you call
> SkBitmap::asImageInfo?

That makes sense.

[scroggo, 2013-12-06 16:09:47]

lgtm

[commit-bot: I haz the power, 2013-12-06 21:07:10]

CQ is trying da patch. Follow status at
https://skia-tree-status.appspot.com/cq/halcanary@google.com/101973005/90001

[commit-bot: I haz the power, 2013-12-06 21:07:14]

Presubmit check for 101973005-90001 failed and returned exit status 1.

Running presubmit commit checks ...

** Presubmit ERRORS **
Since the CL is editing public API, you must have an LGTM from one of:
('reed@chromium.org', 'reed@google.com', 'bsalomon@chromium.org',
'bsalomon@google.com')

[hal.canary, 2013-12-06 22:59:07]

I removed changes to SkData and SkStream.  If those should happen, they can
happen in a later CL.

I specified in comments that the SkData version of the SkDecodingImageGenerator
constructor is preferable.  (There is never any inefficiency wrapping a SkData
in a SkStream.) We should convince Android to use SkData whenever possible.

[reed1, 2013-12-09 13:01:20]

lgtm

[hal.canary, 2013-12-09 13:45:08]

Committed patchset #9 manually as r12560 (presubmit successful).