The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e8148e4aeec049eb1061e3a5a3992b1bbaa260f9

commit e8148e4aeec049eb1061e3a5a3992b1bbaa260f9
Author: Madeleine Barowsky <mbarowsky@chromium.org>
Date: Wed Jan 16 00:46:01 2019

Disable JPEG YUV decoding until full infrastructure for YUV is ready.

The JPEG YUV decoding path is currently unused, despite some previous
support in the decoder and rest of the image pipeline. This change will
ensure that we do not attempt to decode JPEGs into YUV until the
changes for YUV decoding/rendering/caching in CC/Blink have safely landed.

See bit.ly/webp-decoding-into-yuv for the design doc
of that feature and crrev.com/c/1338461 for a working prototype CL.

--

The YUV path is not hit in the common image decoding cases (Canvas2D
and compositor) because JpegImageReader::Decode, which initializes the
|info_| for the reader during size decoding, never sets the decoder's
info |out_color_space| to JCS_YCbCr. The reason is the
"decoder_->HasImagePlanes()" condition:
cs.chromium.org/chromium/src/third_party/blink/renderer/platform/image-decoders/jpeg/jpeg_image_decoder.cc?l=487.

For the metadata decoder used in DeferredImageDecoder the planes are
never set, so it always reports false for CanDecodeToYUV and nothing
downstream tries to use it.

CC has no support for the YUV decoding path; only when we we fallback
to Skia decoding might we potentially hit the GrYUVProvider path
at SkImage_Lazy.cpp:L428.


R=scroggo@chromium.org

Bug:  921101 
Change-Id: I7679fae57a4b01aad78f0307de293c86a27c623f
Reviewed-on: https://chromium-review.googlesource.com/c/1400764
Commit-Queue: Madeleine Barowsky <mbarowsky@chromium.org>
Reviewed-by: Leon Scroggins <scroggo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#622943}
[modify] https://crrev.com/e8148e4aeec049eb1061e3a5a3992b1bbaa260f9/third_party/blink/renderer/platform/image-decoders/jpeg/jpeg_image_decoder.cc