Lazy SKP image decoding in DM.

Lazy SKP image decoding in DM.

@sugoi:
Early out to avoid some segfaults in SkImageDecoder_libjpeg.cpp.
I am just flailing here... things seem to work, but I have no idea why.
This prints out a lot:
    libjpeg error 85 <End Of Image> from output_raw_data [0 0]

@halcanary:
I'm skipping on ImageSrc for now.  Leon's refactoring that quite a lot.

This causes minor diffs for the GPU backend, given that we're now
going through the YUV path.  It also reduced peak RAM usage on
my desktop from 1.26GB to 1.08GB.

BUG=skia:

Committed: https://skia.googlesource.com/skia/+/b3e5e4d314301617d2d48b7589dfd426bd68a671

[mtklein_C, 2015-03-17 20:02:10]

mtklein@chromium.org changed reviewers:
+ halcanary@google.com, sugoi@chromium.org

[mtklein_C, 2015-03-17 20:02:11]

mtklein@chromium.org changed required reviewers:
+ halcanary@google.com, sugoi@chromium.org

[hal.canary, 2015-03-17 21:32:48]

https://codereview.chromium.org/1010983004/diff/1/src/images/SkImageDecoder_l...
File src/images/SkImageDecoder_libjpeg.cpp (right):

https://codereview.chromium.org/1010983004/diff/1/src/images/SkImageDecoder_l...
src/images/SkImageDecoder_libjpeg.cpp:771: static bool
contains_three_planes(const jpeg_decompress_struct& cinfo) {
// Either explain why this is needed or note that you don't know why it is
needed.

[hal.canary, 2015-03-17 21:37:01]

LGTM.  Note that I want to do more ImgSrc/JPEG/PDF testing in the future.

[mtklein, 2015-03-20 20:39:20]

mtklein@google.com changed reviewers:
+ mtklein@google.com

[mtklein, 2015-03-20 20:39:20]

Hey sugoi, any thoughts?

[sugoi1, 2015-03-20 20:52:53]

On 2015/03/20 20:39:20, mtklein wrote:
> Hey sugoi, any thoughts?

Sorry I forgot about this! I have a more complete function in Blink for this:
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...

YUV decoding generally expects:
        (DCTSIZE == 8)
        && (info.num_components == 3)
        && (info.comps_in_scan >= info.num_components)
        && (info.scale_denom <= 8)
        && (info.cur_comp_info[0])
        && (info.cur_comp_info[1])
        && (info.cur_comp_info[2])
        && (info.cur_comp_info[1]->h_samp_factor == 1)
        && (info.cur_comp_info[1]->v_samp_factor == 1)
        && (info.cur_comp_info[2]->h_samp_factor == 1)
        && (info.cur_comp_info[2]->v_samp_factor == 1))

... but I haven't really found examples of JPEG images on the web not respecting
most of these conditions, so I didn't add them to skia, because I didn't have a
real world example to create a test that this accurately fails when hitting some
of these conditions, so since I had no test, I didn't add the code...

[hal.canary, 2015-03-20 20:55:04]

On 2015/03/20 20:52:53, sugoi1 wrote:
> ... but I haven't really found examples of JPEG images on the web not
respecting
> most of these conditions, so I didn't add them to skia, because I didn't have
a
> real world example to create a test that this accurately fails when hitting
some
> of these conditions, so since I had no test, I didn't add the code...

In the Skia repoitorym we have the files resources/CMYK.jpg and
resources/grayscale.jpg that have 4 and 1 components respectively.

[mtklein, 2015-03-20 21:16:57]

Does something like PS3 make sense to you both?

[hal.canary, 2015-03-23 17:58:42]

On 2015/03/20 21:16:57, mtklein wrote:
> Does something like PS3 make sense to you both?

I can't remember if I verbally said patch set 3 lgtm.  But it does.

[mtklein, 2015-03-25 20:06:12]

The CQ bit was checked by mtklein@google.com

[mtklein, 2015-03-25 20:06:13]

The patchset sent to the CQ was uploaded after l-g-t-m from halcanary@google.com
Link to the patchset: https://codereview.chromium.org/1010983004/#ps60001
(title: "double check")

[commit-bot: I haz the power, 2015-03-25 20:06:31]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1010983004/60001

[commit-bot: I haz the power, 2015-03-25 20:06:32]

Note for Reviewers:
The CQ is waiting for an approval.
If you believe that the CL is not ready yet, or if you would like to L-G-T-M
with comments then please uncheck the CQ checkbox.

Waiting for LGTM from valid reviewer(s) till 2015-03-26 02:06 UTC

[mtklein, 2015-03-25 20:07:25]

mtklein@google.com changed required reviewers:
- sugoi@chromium.org

[mtklein, 2015-03-25 20:07:29]

The CQ bit was unchecked by mtklein@google.com

[mtklein, 2015-03-25 20:07:30]

The CQ bit was checked by mtklein@google.com

[commit-bot: I haz the power, 2015-03-25 20:07:41]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1010983004/60001

[commit-bot: I haz the power, 2015-03-25 20:13:47]

Committed patchset #4 (id:60001) as
https://skia.googlesource.com/skia/+/b3e5e4d314301617d2d48b7589dfd426bd68a671

[msarett, 2015-12-21 22:35:56]

msarett@google.com changed reviewers:
+ msarett@google.com

[msarett, 2015-12-21 22:35:57]

https://codereview.chromium.org/1010983004/diff/60001/src/images/SkImageDecod...
File src/images/SkImageDecoder_libjpeg.cpp (right):

https://codereview.chromium.org/1010983004/diff/60001/src/images/SkImageDecod...
src/images/SkImageDecoder_libjpeg.cpp:939: // Seems like jpeg_start_decompress
is updating our opinion of whether cinfo represents YUV.
Mike, I realize this is a shot in the dark, but is there any chance you know
what failure/test image caused this code to be added?  We should be able to to
tell whether YUV is supported before calling jpeg_start_decompress().

My guess is that "info.comps_in_scan" is a bogus thing to check.  And the only
thing that jpeg_start_decompress() might change.  What we really want to know is
whether the image is multi-scan (progressive) or not.  It doesn't look like we
support multi-scan images.

But it would be nice to confirm.

[mtklein, 2015-12-21 23:44:52]

https://codereview.chromium.org/1010983004/diff/60001/src/images/SkImageDecod...
File src/images/SkImageDecoder_libjpeg.cpp (right):

https://codereview.chromium.org/1010983004/diff/60001/src/images/SkImageDecod...
src/images/SkImageDecoder_libjpeg.cpp:939: // Seems like jpeg_start_decompress
is updating our opinion of whether cinfo represents YUV.
On 2015/12/21 22:35:57, msarett wrote:
> Mike, I realize this is a shot in the dark, but is there any chance you know
> what failure/test image caused this code to be added?  We should be able to to
> tell whether YUV is supported before calling jpeg_start_decompress().
> 
> My guess is that "info.comps_in_scan" is a bogus thing to check.  And the only
> thing that jpeg_start_decompress() might change.  What we really want to know
is
> whether the image is multi-scan (progressive) or not.  It doesn't look like we
> support multi-scan images.
> 
> But it would be nice to confirm.

Not sure what image triggered this, but I'm pretty sure I put it right here
because the assert at the beginning of output_raw_data (the next call) was
triggering.  We could try removing it and see what goes wrong?