Move SkDecodingImageGenerator.h to include/

Move SkDecodingImageGenerator.h to include/

This will allow Android to access it and remove SkImageRef.

Depends on https://codereview.chromium.org/293283002/

BUG=skia:2389
Committed: http://code.google.com/p/skia/source/detail?r=14891

[scroggo, 2014-04-08 13:59:49]

Separating this out from https://codereview.chromium.org/223903007/. Mike, I
know you said in that issue you think it's okay for Android to access private
APIs, but Derek has been working on forcing them to use public APIs. I think it
makes sense to continue that trend.

https://codereview.chromium.org/228613003/diff/1/include/lazy/SkDiscardableMe...
File include/lazy/SkDiscardableMemoryPool.h (right):

https://codereview.chromium.org/228613003/diff/1/include/lazy/SkDiscardableMe...
include/lazy/SkDiscardableMemoryPool.h:27: class SkDiscardableMemoryPool :
public SkDiscardableMemory::Factory {
I put this in include/lazy because its source file is in src/lazy. That said,
I'm not sure it doesn't belong in core/, since SkDiscardableMemory is in core/

[scroggo, 2014-05-23 20:07:55]

https://codereview.chromium.org/228613003/diff/1/include/core/SkDiscardableMe...
File include/core/SkDiscardableMemory.h (right):

https://codereview.chromium.org/228613003/diff/1/include/core/SkDiscardableMe...
include/core/SkDiscardableMemory.h:30: class Factory : public SkRefCnt {
I believe I only moved this file for this class. With Hal's change at
https://codereview.chromium.org/293283002/, I no longer need the factory to be
public.

https://codereview.chromium.org/228613003/diff/1/include/images/SkDecodingIma...
File include/images/SkDecodingImageGenerator.h (right):

https://codereview.chromium.org/228613003/diff/1/include/images/SkDecodingIma...
include/images/SkDecodingImageGenerator.h:21: namespace SkDecodingImageGenerator
{
I still need this file to be public though.

https://codereview.chromium.org/228613003/diff/1/include/lazy/SkDiscardableMe...
File include/lazy/SkDiscardableMemoryPool.h (right):

https://codereview.chromium.org/228613003/diff/1/include/lazy/SkDiscardableMe...
include/lazy/SkDiscardableMemoryPool.h:27: class SkDiscardableMemoryPool :
public SkDiscardableMemory::Factory {
On 2014/04/08 13:59:49, scroggo wrote:
> I put this in include/lazy because its source file is in src/lazy. That said,
> I'm not sure it doesn't belong in core/, since SkDiscardableMemory is in core/

Again, Hal's change https://codereview.chromium.org/293283002/ addresses this.

[hal.canary, 2014-05-23 20:30:35]

lgtm

[scroggo, 2014-05-27 13:51:26]

On 2014/05/23 20:30:35, Hal Canary wrote:
> lgtm

Mike, ptal. I need your API approval, and this is the only thing holding us back
from removing SkImageRef.

[reed1, 2014-05-27 14:18:45]

lgtm -- but lets take another look at the (now public) API soon.

1. Do we really need to have a bool for dither?
2. Should it take SkAlphaType instead of a unpremul-bool
3. What does it mean to request or not-request the colortype? Is
kUnknown_SkColorType the same as not-requested?

[scroggo, 2014-05-27 14:53:52]

The CQ bit was checked by scroggo@google.com

[commit-bot: I haz the power, 2014-05-27 14:53:57]

CQ is trying da patch. Follow status at
 https://skia-tree-status.appspot.com/cq/scroggo@google.com/228613003/20001

[commit-bot: I haz the power, 2014-05-27 14:59:50]

Change committed as 14891

[scroggo, 2014-05-27 15:05:11]

On 2014/05/27 14:18:45, reed1 wrote:
> lgtm -- but lets take another look at the (now public) API soon.
> 
> 1. Do we really need to have a bool for dither?

Yes, unless/until we can get Android to not depend on it. I'm pretty sure this
is
explicitly what Android needs to support their existing API.

> 2. Should it take SkAlphaType instead of a unpremul-bool

I don't think so. If a client requests unpremul, the result may end up being
opaque,
so they end up (correctly) with a different SkAlphaType. If the user requests
SkOpaque_SkAlphaType, what would that mean?

> 3. What does it mean to request or not-request the colortype?

I think the dox (see lines 38-42) are pretty clear, but let me know if they
should
be updated. 

> Is
> kUnknown_SkColorType the same as not-requested?

I'm not sure what we should do if the client requests unknown (or what we
currently do).