remove kA1_Config, as it is no longer supported

remove kA1_Config, as it is no longer supported

BUG=
R=djsollen@google.com

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

[hal.canary, 2013-11-25 14:17:58]

Patch set 2 is a bad upload.

[djsollen, 2013-11-25 15:14:14]

I can't see patch set 2 either.

https://codereview.chromium.org/83093005/diff/1/include/core/SkBitmap.h
File include/core/SkBitmap.h (left):

https://codereview.chromium.org/83093005/diff/1/include/core/SkBitmap.h#oldco...
include/core/SkBitmap.h:50: kA1_Config,
this may have some impact in android as they use the int values from this enum
and those will be changing.

[reed1, 2013-11-25 15:52:39]

rebased. ptal

[djsollen, 2013-11-25 18:45:17]

lgtm

[reed1, 2013-11-25 18:58:37]

Committed patchset #3 manually as r12384 (presubmit successful).

[scroggo, 2013-12-02 19:34:35]

https://codereview.chromium.org/83093005/diff/130001/include/core/SkImageDeco...
File include/core/SkImageDecoder.h (right):

https://codereview.chromium.org/83093005/diff/130001/include/core/SkImageDeco...
include/core/SkImageDecoder.h:189: void setPrefConfigTable(const
SkBitmap::Config pref[5]);
Why did this change? The 6 is in reference to the source config possibilities,
not the SkBitmap::Config possibilities.

Android still uses this call, and passes 6 values. (I'm not sure what will
happen to that 6th value.)

https://codereview.chromium.org/83093005/diff/130001/src/utils/debugger/SkObj...
File src/utils/debugger/SkObjectParser.cpp (right):

https://codereview.chromium.org/83093005/diff/130001/src/utils/debugger/SkObj...
src/utils/debugger/SkObjectParser.cpp:29: "None", "A8", "Index8", "RGB565",
"ARGB4444", "ARGB8888"
I'm beginning to think this should truly be global... Oh well.

[cpu_(ooo_6.6-7.5), 2013-12-04 20:01:52]

Scroggo, the answer to your '6' question is that bad things happen. For example
chrome extension system serializes skbitmaps to disk (including the config of
course) so currently in debug ToT chrome explodes because there is no 6.

I think it needs extensions so I don't think the waterfall is going to reflect
this.

Now of course the fault is not exactly with skia since they did not force
clients to literally serialize skbitmaps.

[reed1, 2013-12-04 20:07:21]

On 2013/12/04 20:01:52, cpu wrote:
> Scroggo, the answer to your '6' question is that bad things happen. For
example
> chrome extension system serializes skbitmaps to disk (including the config of
> course) so currently in debug ToT chrome explodes because there is no 6.
> 
> I think it needs extensions so I don't think the waterfall is going to reflect
> this.
> 
> Now of course the fault is not exactly with skia since they did not force
> clients to literally serialize skbitmaps.

Doh! Skia does not yet have a stable way to serialize any of its data
structures. We are very interested in such a thing (esp. at the SkPicture
level), but so far we have not done it.