Support an ALPHA_8 UIResourceBitmap format

Support an ALPHA_8 UIResourceBitmap format

Add an ALPHA_8 UIResourceFormat corresponding to the kAlpha_8_SkColorType. Also
plumb this format to its corresponding ALPHA_8 OpenGL format. This is in
preparation for the UIResource-backed Android L overscroll effect,
https://codereview.chromium.org/367173003/.

BUG=389744
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=289428

[jdduke (slow), 2014-08-11 22:24:30]

aelias@: PTAL.  This works really well with the overscroll effect, and was much
less work than I anticipated.  If it checks out I'll add the requisite owners.

[jdduke (slow), 2014-08-11 22:32:15]

https://codereview.chromium.org/463663002/diff/1/cc/resources/resource_provid...
File cc/resources/resource_provider.cc (right):

https://codereview.chromium.org/463663002/diff/1/cc/resources/resource_provid...
cc/resources/resource_provider.cc:90: case ALPHA_8:
I wasn't sure if this is a format we want to support here? It's not clear to me
what the consequences of this branch are.

[aelias_OOO_until_Jul13, 2014-08-11 23:28:48]

This looks fine to me.

https://codereview.chromium.org/463663002/diff/1/cc/resources/resource_provid...
File cc/resources/resource_provider.cc (right):

https://codereview.chromium.org/463663002/diff/1/cc/resources/resource_provid...
cc/resources/resource_provider.cc:90: case ALPHA_8:
On 2014/08/11 22:32:14, jdduke wrote:
> I wasn't sure if this is a format we want to support here? It's not clear to
me
> what the consequences of this branch are.

This is an experimental fast-path for texture upload.  It's fine to return false
as you're doing here (that just means normal texture upload will always be used
for these).

[jdduke (slow), 2014-08-12 00:09:45]

Thanks in advance for owner review.

ccameron@: cc/resources, content/browser/compositor
davemoore@: mojo/services/public

[jamesr, 2014-08-12 00:15:58]

mojo/ lgtm

[jdduke (slow), 2014-08-13 16:52:35]

epenner@: Could you review the changes to cc/resources? Thanks.

[danakj, 2014-08-13 17:17:28]

https://codereview.chromium.org/463663002/diff/20001/cc/resources/resource_fo...
File cc/resources/resource_format.h (right):

https://codereview.chromium.org/463663002/diff/20001/cc/resources/resource_fo...
cc/resources/resource_format.h:18: ALPHA_8,
May I ask so I can answer this in the future, why do we need both this and
LUMINANCE_8 in here?

[jdduke (slow), 2014-08-13 18:01:57]

https://codereview.chromium.org/463663002/diff/20001/cc/resources/resource_fo...
File cc/resources/resource_format.h (right):

https://codereview.chromium.org/463663002/diff/20001/cc/resources/resource_fo...
cc/resources/resource_format.h:18: ALPHA_8,
On 2014/08/13 17:17:27, danakj wrote:
> May I ask so I can answer this in the future, why do we need both this and
> LUMINANCE_8 in here?

Each corresponds to a distinct GL format that has very different semantics.
ALPHA_8 effectively provides a black RGB texture with pixel-varying alpha
values. LUMINANCE_8 provides a grayscale RGB texture with pixel-varying
intensities but a constant alpha of 1.

[jdduke (slow), 2014-08-13 18:07:15]

https://codereview.chromium.org/463663002/diff/20001/cc/resources/resource_fo...
File cc/resources/resource_format.h (right):

https://codereview.chromium.org/463663002/diff/20001/cc/resources/resource_fo...
cc/resources/resource_format.h:18: ALPHA_8,
On 2014/08/13 18:01:57, jdduke wrote:
> On 2014/08/13 17:17:27, danakj wrote:
> > May I ask so I can answer this in the future, why do we need both this and
> > LUMINANCE_8 in here?
> 
> Each corresponds to a distinct GL format that has very different semantics.
> ALPHA_8 effectively provides a black RGB texture with pixel-varying alpha
> values. LUMINANCE_8 provides a grayscale RGB texture with pixel-varying
> intensities but a constant alpha of 1.

I suppose it might be able to achieve the same effect with LUMINANCE using the
proper blending function, but our blending mode support currently appears to be
somewhat limited.

[danakj, 2014-08-13 18:46:06]

https://codereview.chromium.org/463663002/diff/20001/cc/resources/resource_fo...
File cc/resources/resource_format.h (right):

https://codereview.chromium.org/463663002/diff/20001/cc/resources/resource_fo...
cc/resources/resource_format.h:18: ALPHA_8,
On 2014/08/13 18:07:15, jdduke wrote:
> On 2014/08/13 18:01:57, jdduke wrote:
> > On 2014/08/13 17:17:27, danakj wrote:
> > > May I ask so I can answer this in the future, why do we need both this and
> > > LUMINANCE_8 in here?
> > 
> > Each corresponds to a distinct GL format that has very different semantics.
> > ALPHA_8 effectively provides a black RGB texture with pixel-varying alpha
> > values. LUMINANCE_8 provides a grayscale RGB texture with pixel-varying
> > intensities but a constant alpha of 1.
> 
> I suppose it might be able to achieve the same effect with LUMINANCE using the
> proper blending function, but our blending mode support currently appears to
be
> somewhat limited.

Which blending functions are you refering to here?

[jdduke (slow), 2014-08-13 18:53:37]

https://codereview.chromium.org/463663002/diff/20001/cc/resources/resource_fo...
File cc/resources/resource_format.h (right):

https://codereview.chromium.org/463663002/diff/20001/cc/resources/resource_fo...
cc/resources/resource_format.h:18: ALPHA_8,
On 2014/08/13 18:46:06, danakj wrote:
> Which blending functions are you refering to here?

Layer::SetBlendMode(SkXfermode::Mode blend_mode). I tried a few of the supported
modes blindly, but none of them yielded the desired effect (referring to
https://codereview.chromium.org/367173003/). Of note, Android L's overscroll
effect happens to use the kSrcATop_Mode, which  doesn't appear to be supported. 

RGBA8 works just fine, but we were under the impression that the ALPHA_8 format
could save us some memory along the way.

[danakj, 2014-08-13 22:01:47]

On 2014/08/13 18:53:37, jdduke wrote:
>
https://codereview.chromium.org/463663002/diff/20001/cc/resources/resource_fo...
> File cc/resources/resource_format.h (right):
> 
>
https://codereview.chromium.org/463663002/diff/20001/cc/resources/resource_fo...
> cc/resources/resource_format.h:18: ALPHA_8,
> On 2014/08/13 18:46:06, danakj wrote:
> > Which blending functions are you refering to here?
> 
> Layer::SetBlendMode(SkXfermode::Mode blend_mode). I tried a few of the
supported
> modes blindly, but none of them yielded the desired effect (referring to
> https://codereview.chromium.org/367173003/). Of note, Android L's overscroll
> effect happens to use the kSrcATop_Mode, which  doesn't appear to be
supported. 

SrcATop means that only draws where the destination is currently transparent?
I'm not sure how that would be related, what am I missing there?

I would have thought you could use like a FilterOperation with a ColorMatrix or
something, to change the way the texture's color channel(s) is/are treated
without having to write a custom shader path.

I guess OpenGL supports this already tho and you can just use that also.

Randomly, you still will need to support ETC1 also?

> RGBA8 works just fine, but we were under the impression that the ALPHA_8
format
> could save us some memory along the way.

[jdduke (slow), 2014-08-13 22:06:26]

Hmm, just kidding, epenner@ is out of town. Sorry for the noise, davemoore@
would you mind taking a look? Thanks.

[aelias_OOO_until_Jul13, 2014-08-13 22:08:27]

Yeah, I think Jared's point was just that there are many ways to achieve the
same effect, but adding support for ALPHA_8 is the lowest-hanging.  Note that
Skia already understands Alpha8 but has no concept of Luminance8.  We could've
added Luminance8 support to Skia instead, but alpha is a better fit for our
needs here anyway (it works out of the box without needing any new shader, blend
mode, matrix or whatever).

We still want to support ETC1 because it's much smaller than Alpha8 (4 bits per
pixel).  But ETC1 would look artifacted for the L overscroll use case which has
a crisp curve.

[jdduke (slow), 2014-08-13 22:08:57]

On 2014/08/13 22:01:47, danakj wrote:
> SrcATop means that only draws where the destination is currently transparent?
> I'm not sure how that would be related, what am I missing there?

Oh, that particular mode is not necessary for the effect. I mentioned it only as
an example of an unsupported blend function, having bumped into it recently when
porting the Android L effect.

[danakj, 2014-08-13 22:17:37]

Cool, thanks for all the explanation, cc LGTM

[jdduke (slow), 2014-08-13 23:09:54]

The CQ bit was checked by jdduke@chromium.org

[commit-bot: I haz the power, 2014-08-13 23:11:40]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/jdduke@chromium.org/463663002/20001

[jdduke (slow), 2014-08-14 00:05:07]

Thanks for review!

[commit-bot: I haz the power, 2014-08-14 00:44:11]

Committed patchset #2 (20001) as 289428