Rename kPMColor_SkColorType to kN32_SkColorType.

Rename kPMColor_SkColorType to kN32_SkColorType.

The new name better represents what this flag means.

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

[scroggo, 2014-04-07 21:35:48]

https://codereview.chromium.org/227433009/diff/1/gyp/common.gypi
File gyp/common.gypi (right):

https://codereview.chromium.org/227433009/diff/1/gyp/common.gypi#newcode18
gyp/common.gypi:18: 'SK_SUPPORT_LEGACY_N32_NAME',
It will be easy to search and replace to change, once we're sure we're happy
with the new name. Then this flag can be removed (and we'll need to add it to
chromium).

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

https://codereview.chromium.org/227433009/diff/1/include/core/SkImageInfo.h#n...
include/core/SkImageInfo.h:82: #if SK_PMCOLOR_BYTE_ORDER(B,G,R,A)
In theory we should change this as well. SK_N32_BYTE_ORDER? (It appears Chrome
does not use this one, so we can just change it in one CL.)

https://codereview.chromium.org/227433009/diff/1/include/core/SkImageInfo.h#n...
include/core/SkImageInfo.h:83: kN32_SkColorType = kBGRA_8888_SkColorType,
I went with your suggesting here, but I'd be happy with k(N | Native)(32 |
8888)_SkColorType.

8888 follows the convention of the other enums (though 32 follows the convention
of the factories).

Native gives a little more info (again N follows the convention of the
factories).

[reed1, 2014-04-08 13:04:57]

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

https://codereview.chromium.org/227433009/diff/1/include/core/SkImageInfo.h#n...
include/core/SkImageInfo.h:90: #ifdef SK_SUPPORT_LEGACY_N32_NAME
I suggest we ...

1. don't add a guard until we have removed all of skia's references to the old
name
2. add the guard in chrome's skia/skia_common.gypi or our
gyp/skia_for_chrome.gypi

[scroggo, 2014-04-08 14:46:28]

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

https://codereview.chromium.org/227433009/diff/1/include/core/SkImageInfo.h#n...
include/core/SkImageInfo.h:90: #ifdef SK_SUPPORT_LEGACY_N32_NAME
On 2014/04/08 13:04:57, reed1 wrote:
> I suggest we ...
> 
> 1. don't add a guard until we have removed all of skia's references to the old
> name

I 100% agree. I'd like to make the change in another patch to this CL, but I
want to make sure you like the new name before doing the search and replace.

> 2. add the guard in chrome's skia/skia_common.gypi or our
> gyp/skia_for_chrome.gypi

Done.

[scroggo, 2014-04-08 19:38:10]

It's a lot to look at, but I've renamed all our uses of kPMColor_SkColorType to
kN32_SkColorType.

I also removed the define of the legacy flag in common.gypi (so now it will only
be defined by chrome).

Should I also change SK_PMCOLOR_BYTE_ORDER in this CL? Perhaps it should be
SK_N32_BYTE_ORDER.... Or maybe not; we still have SkPMColor, which has the same
order as N32, and implies premultiplied (though we don't have an equivalent for
unpremultiplied - perhaps that's not necessary though).

https://codereview.chromium.org/227433009/diff/40001/gyp/common_conditions.gypi
File gyp/common_conditions.gypi (right):

https://codereview.chromium.org/227433009/diff/40001/gyp/common_conditions.gy...
gyp/common_conditions.gypi:305: 'kNative_8888_SkColorType kN32_SkColorType',
On Android I used kNative_8888, but I can switch them over to kN32 if we like
that better.

[reed1, 2014-04-09 12:30:01]

lgtm

[scroggo, 2014-04-09 19:01:10]

The CQ bit was checked by scroggo@google.com

[commit-bot: I haz the power, 2014-04-09 19:01:26]

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

[scroggo, 2014-04-09 19:14:13]

The CQ bit was checked by scroggo@google.com

[commit-bot: I haz the power, 2014-04-09 19:14:22]

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

[commit-bot: I haz the power, 2014-04-09 20:46:26]

Change committed as 14117

[benchen, 2014-04-10 22:35:48]

A revert of this CL has been created in
https://codereview.chromium.org/234243002/ by bensong@google.com.

The reason for reverting is: breaking the Chrome deps roll.
http://build.chromium.org/p/chromium.linux/builders/Linux%20GN%20%28dbg%29/bu....

[benchen, 2014-04-11 13:46:39]

A revert of this CL has been created in
https://codereview.chromium.org/234833003/ by bensong@google.com.

The reason for reverting is: Chrome's side of define changes not easy to figure
out quickly. Reverting this for DEPS roll for now..

[scroggo, 2014-04-11 14:33:52]

On 2014/04/11 13:46:39, benchen wrote:
> A revert of this CL has been created in
> https://codereview.chromium.org/234833003/ by mailto:bensong@google.com.
> 
> The reason for reverting is: Chrome's side of define changes not easy to
figure
> out quickly. Reverting this for DEPS roll for now..

Derek tells me this was only breaking GN, which has been fixed. Safe to go ahead
and resubmit, or should I just wait for the DEPS roll just in case?

[benchen, 2014-04-11 14:41:41]

On 2014/04/11 14:33:52, scroggo wrote:
> On 2014/04/11 13:46:39, benchen wrote:
> > A revert of this CL has been created in
> > https://codereview.chromium.org/234833003/ by mailto:bensong@google.com.
> > 
> > The reason for reverting is: Chrome's side of define changes not easy to
> figure
> > out quickly. Reverting this for DEPS roll for now..
> 
> Derek tells me this was only breaking GN, which has been fixed. Safe to go
ahead
> and resubmit, or should I just wait for the DEPS roll just in case?

Let's check back after lunch.

[benchen, 2014-04-11 16:56:37]

On 2014/04/11 14:41:41, benchen wrote:
> On 2014/04/11 14:33:52, scroggo wrote:
> > On 2014/04/11 13:46:39, benchen wrote:
> > > A revert of this CL has been created in
> > > https://codereview.chromium.org/234833003/ by mailto:bensong@google.com.
> > > 
> > > The reason for reverting is: Chrome's side of define changes not easy to
> > figure
> > > out quickly. Reverting this for DEPS roll for now..
> > 
> > Derek tells me this was only breaking GN, which has been fixed. Safe to go
> ahead
> > and resubmit, or should I just wait for the DEPS roll just in case?
> 
> Let's check back after lunch.

the roll looks good so far, please feel free to resubmit. Thanks for the
patience Leon!

[scroggo, 2014-04-11 17:07:54]

On 2014/04/11 16:56:37, benchen wrote:
> On 2014/04/11 14:41:41, benchen wrote:
> > On 2014/04/11 14:33:52, scroggo wrote:
> > > On 2014/04/11 13:46:39, benchen wrote:
> > > > A revert of this CL has been created in
> > > > https://codereview.chromium.org/234833003/ by mailto:bensong@google.com.
> > > > 
> > > > The reason for reverting is: Chrome's side of define changes not easy to
> > > figure
> > > > out quickly. Reverting this for DEPS roll for now..
> > > 
> > > Derek tells me this was only breaking GN, which has been fixed. Safe to go
> > ahead
> > > and resubmit, or should I just wait for the DEPS roll just in case?
> > 
> > Let's check back after lunch.
> 
> the roll looks good so far, please feel free to resubmit. Thanks for the
> patience Leon!

Hmm, the commit checkbox is greyed out. Created
https://codereview.chromium.org/232773007 to reland.

[benchen, 2014-04-11 17:10:30]

On 2014/04/11 17:07:54, scroggo wrote:
> On 2014/04/11 16:56:37, benchen wrote:
> > On 2014/04/11 14:41:41, benchen wrote:
> > > On 2014/04/11 14:33:52, scroggo wrote:
> > > > On 2014/04/11 13:46:39, benchen wrote:
> > > > > A revert of this CL has been created in
> > > > > https://codereview.chromium.org/234833003/ by
mailto:bensong@google.com.
> > > > > 
> > > > > The reason for reverting is: Chrome's side of define changes not easy
to
> > > > figure
> > > > > out quickly. Reverting this for DEPS roll for now..
> > > > 
> > > > Derek tells me this was only breaking GN, which has been fixed. Safe to
go
> > > ahead
> > > > and resubmit, or should I just wait for the DEPS roll just in case?
> > > 
> > > Let's check back after lunch.
> > 
> > the roll looks good so far, please feel free to resubmit. Thanks for the
> > patience Leon!
> 
> Hmm, the commit checkbox is greyed out. Created
> https://codereview.chromium.org/232773007 to reland.

We could've done a revert click of the revert here
https://codereview.chromium.org/234243002/ but either way is fine :)

[scroggo, 2014-04-11 17:22:34]

On 2014/04/11 17:10:30, benchen wrote:
> On 2014/04/11 17:07:54, scroggo wrote:
> > On 2014/04/11 16:56:37, benchen wrote:
> > > On 2014/04/11 14:41:41, benchen wrote:
> > > > On 2014/04/11 14:33:52, scroggo wrote:
> > > > > On 2014/04/11 13:46:39, benchen wrote:
> > > > > > A revert of this CL has been created in
> > > > > > https://codereview.chromium.org/234833003/ by
> mailto:bensong@google.com.
> > > > > > 
> > > > > > The reason for reverting is: Chrome's side of define changes not
easy
> to
> > > > > figure
> > > > > > out quickly. Reverting this for DEPS roll for now..
> > > > > 
> > > > > Derek tells me this was only breaking GN, which has been fixed. Safe
to
> go
> > > > ahead
> > > > > and resubmit, or should I just wait for the DEPS roll just in case?
> > > > 
> > > > Let's check back after lunch.
> > > 
> > > the roll looks good so far, please feel free to resubmit. Thanks for the
> > > patience Leon!
> > 
> > Hmm, the commit checkbox is greyed out. Created
> > https://codereview.chromium.org/232773007 to reland.
> 
> We could've done a revert click of the revert here
> https://codereview.chromium.org/234243002/ but either way is fine :)

Done. This way I didn't have to wait for pesky API approval etc.

[reed1, 2014-04-11 17:35:04]

pesky lgtm