Add option to SkDecodingImageGenerator to require unpremul.

Add option to SkDecodingImageGenerator to require unpremul.

Android needs to be able to set unpremul for purgeable
pixelRefs.

Once Android switches to the new interface, we can delete SkImageRef.

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

[scroggo, 2014-04-03 20:49:50]

I discussed this with Hal, and he pointed out that ashmem is handled by
SkDiscardableMemory::Create, when the factory is NULL.

He also said he would prefer to keep SkDiscardableMemoryPool private. This is
fine with me, although we'll need to add a way to call
SkGetGlobalDiscardableMemoryPool() that is exposed in include.

We also need a way to specify the size of the pool, but that can be done just by
using SK_DEFAULT_GLOBAL_DISCARDABLE_MEMORY_POOL_SIZE in SkUserConfig.

[hal.canary, 2014-04-04 17:49:30]

After https://codereview.chromium.org/223403012, you can go ahead and move
SkDiscardableMemoryPool.h as well as SkDiscardableMemory.h into include/ without
exposing any implementation details.

[reed1, 2014-04-07 13:22:06]

Not sure what issue this fixes for android.

[scroggo, 2014-04-07 13:29:00]

On 2014/04/07 13:22:06, reed1 wrote:
> Not sure what issue this fixes for android.

This is on the way to switching Android off SkImageRef so we can delete it.

It does not fix any Android bugs.

(I still need to rebase it on top of https://codereview.chromium.org/226253003/
and https://codereview.chromium.org/223403012.

[hal.canary, 2014-04-07 13:30:27]

On 2014/04/07 13:22:06, reed1 wrote:
> Not sure what issue this fixes for android.

I think  Leon is saying that they need these new functions
(SkDecodingImageGenerator::Create, SkGetGlobalDiscardableMemoryPool, etc)
exposed in include/.

[scroggo, 2014-04-07 13:32:58]

On 2014/04/07 13:30:27, Hal Canary wrote:
> On 2014/04/07 13:22:06, reed1 wrote:
> > Not sure what issue this fixes for android.
> 
> I think  Leon is saying that they need these new functions
> (SkDecodingImageGenerator::Create, SkGetGlobalDiscardableMemoryPool, etc)
> exposed in include/.

Yes, because we do not want them calling headers which are hidden in src/.

This CL makes another change, which is to make SkDecodingImageGenerator support
unpremultiplied decoding.

[reed1, 2014-04-07 14:40:37]

Maybe this publicization is correct, but if it is only for android, I'm fine for
the framework to have private access to things.

[scroggo, 2014-04-07 18:16:39]

On 2014/04/07 14:40:37, reed1 wrote:
> Maybe this publicization is correct, but if it is only for android, I'm fine
for
> the framework to have private access to things.

Derek is trying to remove Android's private access to Skia code.

Either way, Android needs to be able to decode into unpremul for purgeable
decodes,
so I am splitting this change into two CLs. This one only modifies the class to
add the new option.

PTAL.

[reed1, 2014-04-07 18:21:12]

https://codereview.chromium.org/223903007/diff/10001/src/images/SkDecodingIma...
File src/images/SkDecodingImageGenerator.cpp (right):

https://codereview.chromium.org/223903007/diff/10001/src/images/SkDecodingIma...
src/images/SkDecodingImageGenerator.cpp:38: const bool            
fRequireUnpremul;
why isn't this deducible from fInfo?

[scroggo, 2014-04-07 19:00:12]

https://codereview.chromium.org/223903007/diff/10001/src/images/SkDecodingIma...
File src/images/SkDecodingImageGenerator.cpp (right):

https://codereview.chromium.org/223903007/diff/10001/src/images/SkDecodingIma...
src/images/SkDecodingImageGenerator.cpp:38: const bool            
fRequireUnpremul;
On 2014/04/07 18:21:12, reed1 wrote:
> why isn't this deducible from fInfo?

Done. (I'm actually deducing it from the passed in info to getPixels.)

[reed1, 2014-04-07 19:55:22]

lgtm

[scroggo, 2014-04-07 21:10:03]

The CQ bit was checked by scroggo@google.com

[commit-bot: I haz the power, 2014-04-07 21:10:13]

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

[commit-bot: I haz the power, 2014-04-07 21:37:39]

Change committed as 14084