Add support for decoding to 565 to libjpeg_turbo

Add support for decoding to 565 to libjpeg_turbo

It was submitted upstream at libjpeg_turbo as r1295 plus
sundry fixes and SIMD optimizations (r1385, r1386, r1398,
and r1402).  Now cherry pick the change into
third_party/libjpeg-turbo.

At this time, this new capability is intended for Android
devices, not Chrome, and should have no affect on JPEG
decode behavior or perf of Chrome.

BUG=516761
R=noel@chromium.org

Committed: https://chromium.googlesource.com/chromium/deps/libjpeg_turbo/+/feec46f80444b8eed4126a86a2c0e2cffe1c9673

[msarett, 2015-08-04 18:45:47]

Patchset #1 (id:1) has been deleted

[msarett, 2015-08-04 18:47:56]

Patchset #1 (id:20001) has been deleted

[msarett, 2015-08-04 18:56:03]

msarett@google.com changed reviewers:
+ noel@chromium.org, scroggo@chromium.org

[msarett, 2015-08-04 18:56:03]

https://codereview.chromium.org/1270213002/diff/40001/jpeglibmangler.h
File jpeglibmangler.h (right):

https://codereview.chromium.org/1270213002/diff/40001/jpeglibmangler.h#newcod...
jpeglibmangler.h:114: #define jpeg_natural_order chromium_jpeg_natural_order
These are not a part of the 565 decoding support patch and I'm happy to remove
these if you think I should.  Skia currently compiles two different copies of
libjpeg, so it fails to link without name mangling.  A linking failure indicated
that these names were missing from this file.

[Noel Gordon, 2015-08-04 23:58:16]

https://codereview.chromium.org/1270213002/diff/40001/jdcol565.c
File jdcol565.c (right):

https://codereview.chromium.org/1270213002/diff/40001/jdcol565.c#newcode1
jdcol565.c:1: /*
This file is new. Does it need to be added to the libjpeg_turbo.{gyp,gn} files
so chromium will compile?

https://codereview.chromium.org/1270213002/diff/40001/jdmrg565.c
File jdmrg565.c (right):

https://codereview.chromium.org/1270213002/diff/40001/jdmrg565.c#newcode1
jdmrg565.c:1: /*
This file is new. Does it need to be added to the libjpeg_turbo.{gyp,gn} files
so chromium will compile?

https://codereview.chromium.org/1270213002/diff/40001/jpeglibmangler.h
File jpeglibmangler.h (right):

https://codereview.chromium.org/1270213002/diff/40001/jpeglibmangler.h#newcod...
jpeglibmangler.h:114: #define jpeg_natural_order chromium_jpeg_natural_order
On 2015/08/04 18:56:03, msarett wrote:
> These are not a part of the 565 decoding support patch and I'm happy to remove
> these if you think I should.  Skia currently compiles two different copies of
> libjpeg, so it fails to link without name mangling.  A linking failure
indicated
> that these names were missing from this file.

Seems fine.

[Noel Gordon, 2015-08-05 00:10:50]

https://codereview.chromium.org/1270213002/diff/40001/README.chromium
File README.chromium (right):

https://codereview.chromium.org/1270213002/diff/40001/README.chromium#newcode24
README.chromium:24: trunk to enable decoding to 565 as a memory optimization;
Thanks for creating bugs and adding references to them.  One thought ...

Maybe "CR Bug 516761:" could go, and we instead append a bug URL after the text
(easy from my editor or terminal to navigate to the bug that way)?

*  Revisions r1295, r1385, r1398, and r1402 (r1386 is also ...
   trunk to enable decoding to 565 as a memory optimization;
   http://crbug.com/516761

[msarett, 2015-08-05 13:41:08]

https://codereview.chromium.org/1270213002/diff/40001/README.chromium
File README.chromium (right):

https://codereview.chromium.org/1270213002/diff/40001/README.chromium#newcode24
README.chromium:24: trunk to enable decoding to 565 as a memory optimization;
On 2015/08/05 00:10:50, noel gordon wrote:
> Thanks for creating bugs and adding references to them.  One thought ...
> 
> Maybe "CR Bug 516761:" could go, and we instead append a bug URL after the
text
> (easy from my editor or terminal to navigate to the bug that way)?
> 
> *  Revisions r1295, r1385, r1398, and r1402 (r1386 is also ...
>    trunk to enable decoding to 565 as a memory optimization;
>    http://crbug.com/516761
> 
>  

Sound good, done!

https://codereview.chromium.org/1270213002/diff/40001/jdcol565.c
File jdcol565.c (right):

https://codereview.chromium.org/1270213002/diff/40001/jdcol565.c#newcode1
jdcol565.c:1: /*
On 2015/08/04 23:58:16, noel gordon wrote:
> This file is new. Does it need to be added to the libjpeg_turbo.{gyp,gn} files
> so chromium will compile?

This file is included by jdcolor.c (similar to jdcolext.c), so it does not need
to be added to the gyp file.

https://codereview.chromium.org/1270213002/diff/40001/jdmrg565.c
File jdmrg565.c (right):

https://codereview.chromium.org/1270213002/diff/40001/jdmrg565.c#newcode1
jdmrg565.c:1: /*
On 2015/08/04 23:58:16, noel gordon wrote:
> This file is new. Does it need to be added to the libjpeg_turbo.{gyp,gn} files
> so chromium will compile?

This file is included by jdmerge.c, so it does not need to be added to the gyp
file.

[Noel Gordon, 2015-08-05 14:03:08]

On 2015/08/05 13:41:08, msarett wrote:
> https://codereview.chromium.org/1270213002/diff/40001/README.chromium
> File README.chromium (right):
> 
>
https://codereview.chromium.org/1270213002/diff/40001/README.chromium#newcode24
> README.chromium:24: trunk to enable decoding to 565 as a memory optimization;
> On 2015/08/05 00:10:50, noel gordon wrote:
> > Thanks for creating bugs and adding references to them.  One thought ...
> > 
> > Maybe "CR Bug 516761:" could go, and we instead append a bug URL after the
> text
> > (easy from my editor or terminal to navigate to the bug that way)?
> > 
> > *  Revisions r1295, r1385, r1398, and r1402 (r1386 is also ...
> >    trunk to enable decoding to 565 as a memory optimization;
> >    http://crbug.com/516761
> > 
> >  
> 
> Sound good, done!

Thanks, and nod re the auto inclusion of the other files mentioned so no gyp
updates needed.  Thanks for checking.

[Noel Gordon, 2015-08-05 14:03:18]

LGTM

[msarett, 2015-08-05 14:33:04]

Are you able to land this for me?  I don't think I have the permissions.

[agable, 2015-08-06 16:54:53]

Committed patchset #2 (id:60001) manually as
feec46f80444b8eed4126a86a2c0e2cffe1c9673 (presubmit successful).