Add jpeg_skip_scanlines() API to libjpeg-turbo

Add jpeg_skip_scanlines() API to libjpeg-turbo

jpeg_skip_scanlines() API, a subset decoding optimization
aimed at Android, was submitted upstream r1582. Pull that
change, and sundry fixes, into the Chromium repo.

This new API is targetted at Android devices, not Chrome,
and should have no affect on JPEG decode behavior or perf
of Chrome.

Chrome uses suspending data source JPEG decoding, and the
new API does not support such sources. Adding support for
suspending data sources is a future TODO, should the need
arise (refer to skbug.com/4036).

BUG=515694
BUG=468914

[msarett1, 2015-07-30 20:37:40]

Sorry for needing to create a new issue.

The fact that I couldn't merge this one with the old issue is probably a good
indication that I was doing something wrong.

Thanks for the instructions Noel!

[noel chromium, 2015-07-30 20:54:43]

On 2015/07/30 20:37:40, msarett1 wrote:
> Sorry for needing to create a new issue.

No worries.

> The fact that I couldn't merge this one with the old issue is probably a good
> indication that I was doing something wrong.

Yeap, there are always some mechanics to deal with, so we provide (hopefully
good) instructions.

I'd suggest you remove libjpeg.txt from the patch, unless you have some need to
include it. Typically, I just google for it.

[msarett1, 2015-07-30 21:30:22]

libjpeg.txt is removed.

[noel chromium, 2015-07-30 21:42:46]

For some reason I can't edit this issue.  Can you make sure only
noel@chromium.org is in the reviewers list and we'll see if that fixes it?

[noel chromium, 2015-07-30 22:32:10]

On 2015/07/30 21:42:46, noel chromium wrote:
> For some reason I can't edit this issue.  Can you make sure only
> mailto:noel@chromium.org is in the reviewers list and we'll see if that fixes
it?

Actually, that's just the way it is :/  I suggested the change description over
on https://codereview.chromium.org/1258673007 so you can bring it here.

[msarett1, 2015-07-31 13:04:59]

"Yes, you should only include the files you changed.  On the other hand, I think
that google.patch has become a burden.  There is a simple way to compute it, but
it is simply non-obvious.  One option is we get rid of it, and better document
our changes using bugs etc in the README.chromium file."

I would agree that it seems the google.patch file has gotten a little too big to
be useful.  I have removed it and tried to add extra information to
README.chromium.

"Second thing, I was not able to edit your change on the new issue, and it needs
some edits, so I did those here.  Could you copy them over to your new review
issue, please?"

The issue description has been updated.

[noel chromium, 2015-07-31 15:50:09]

On 2015/07/31 13:04:59, msarett1 wrote:
> "Yes, you should only include the files you changed.  On the other hand, I
think
> that google.patch has become a burden.  There is a simple way to compute it,
but
> it is simply non-obvious.  One option is we get rid of it, and better document
> our changes using bugs etc in the README.chromium file."
> 
> I would agree that it seems the google.patch file has gotten a little too big
to
> be useful.  I have removed it and tried to add extra information to
> README.chromium.

Yes I think that is the way forward form this point on.  Better document the
changes, add bug references (I opened a bug for this CL issue) etc, to help
track the work.

> "Second thing, I was not able to edit your change on the new issue, and it
needs
> some edits, so I did those here.  Could you copy them over to your new review
> issue, please?"
> 
> The issue description has been updated.

Thanks, now you need to manually land this patch by following those
instructions, and record the git hash of the commit -- you will need the hash
when roll this change into chrome.

As an example roll, and if you have a chrome checkout

  % git log c038962a97c41089b6ef09f498bfd934be95b5cc

or see https://codereview.chromium.org/1110113002

[noel chromium, 2015-07-31 15:50:35]

LGTM

[noel chromium, 2015-07-31 15:53:55]

Also, is this part of bug 468914?  Add that to your BUG= line if so.

[msarett1, 2015-08-03 13:22:57]

>msarett@msarett1:/usr/local/google/chromium/src/third_party/libjpeg_turbo$ git
cl land
>Using 50% similarity for rename/copy detection. Override with --similarity.
>Running presubmit commit checks ...
>
>Presubmit checks passed.
>Description:
>Add jpeg_skip_scanlines() API to libjpeg-turbo
>
>jpeg_skip_scanlines() API, a subset decoding optimization
>aimed at Android, was submitted upstream r1582. Pull that
>change, and sundry fixes, into the Chromium repo.

>This new API is targetted at Android devices, not Chrome,
>and should have no affect on JPEG decode behavior or perf
>of Chrome.
>
>Chrome uses suspending data source JPEG decoding, and the
>new API does not support such sources. Adding support for
>suspending data sources is a future TODO, should the need
>arise (refer to skbug.com/4036).
>
>BUG=515694
>BUG=468914
>R=noel@chromium.org
>
>Review URL: https://codereview.appspot.com/256280043 .
> README.chromium  |   22 +-
> djpeg.c          |   89 ++-
> google.patch     | 4438
-------------------------------------------------------------------------------------------------------------
> jdapistd.c       |  240 +++++-
> jdarith.c        |   12 +-
> jdcoefct.c       |   74 +-
> jdcoefct.h       |   82 ++
> jdhuff.c         |   17 +-
> jdmainct.c       |   63 +-
> jdmainct.h       |   71 ++
> jdsample.c       |   41 +-
> jdsample.h       |   50 ++
> jpeglib.h        |    3 +
> jpeglibmangler.h |    1 +
> 14 files changed, 557 insertions(+), 4646 deletions(-)
>Counting objects: 15, done.
>Delta compression using up to 40 threads.
>Compressing objects: 100% (15/15), done.
>Writing objects: 100% (15/15), 9.01 KiB | 0 bytes/s, done.
>Total 15 (delta 11), reused 0 (delta 0)
>remote: Resolving deltas: 100% (11/11)
>remote: Processing changes: refs: 1, done    
>error: failed to push some refs to
'https://chromium.googlesource.com/chromium/deps/libjpeg_turbo.git'
>Failed to push. If this persists, please file a bug.

I was unable to land my changes with the error message above.  I tried to
reconfigure the issue and now I have a worse error message.

>msarett@msarett1:/usr/local/google/chromium/src/third_party/libjpeg_turbo$ git
cl land
>Using 50% similarity for rename/copy detection. Override with --similarity.

>While fetching the description for issue 256280043, received a 404 (not found)
>error. It is likely that you deleted this issue on the server. If this is the
>case, please run
>
>    git cl issue 0
>
>to clear the association with the deleted issue. Then run this command again.

I'm still trying to figure things out, but if anyone has any insight into what's
going on, please let me know!

[noel chromium, 2015-08-03 13:44:47]

Not sure what's going on. Could you ping agable@ about it?