Change quality settings on SkImageDecoder_libjpeg

Change quality settings on SkImageDecoder_libjpeg

It has been demonstrated that higher quality settings
really do make a difference in the visual quality of
the output image.
https://code.google.com/p/chromium/issues/detail?id=385515
https://code.google.com/p/skia/issues/detail?id=3770

We are planning to replace SkImageDecoder with SkCodec,
and SkCodec will use the higher quality settings.  As
a first step, we are using SkCodec as the underlying
implementation for BitmapRegionDecoder.  CTS tests require
that BitmapRegionDecoder be a close match to BitmapFactory
(which uses SkImageDecoder), so we must also update the
quality of SkImageDecoder to maintain CTS compatibility.

BUG=skia:

Committed: https://skia.googlesource.com/skia/+/69ad6a9d03dd6f14b7c730465319313725a7c903

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

[msarett, 2015-11-06 00:10:47]

Description was changed from

==========
Change settings on SkImageDecoder

BUG=skia:
==========

to

==========
Change quality settings on SkImageDecoder

It has been demonstrated that higher quality settings
really do make a difference in the visual quality of
the output image.
https://code.google.com/p/chromium/issues/detail?id=385515
https://code.google.com/p/skia/issues/detail?id=3770

We are planning to replace SkImageDecoder with SkCodec,
and SkCodec will use the higher quality settings.  As
a first step, we are using SkCodec as the underlying
implementation for BitmapRegionDecoder.  CTS tests require
that BitmapRegionDecoder be a close match to BitmapFactory
(which uses SkImageDecoder), so we must also update the
quality of SkImageDecoder.

BUG=skia:
==========

[msarett, 2015-11-06 00:11:08]

Description was changed from

==========
Change quality settings on SkImageDecoder

It has been demonstrated that higher quality settings
really do make a difference in the visual quality of
the output image.
https://code.google.com/p/chromium/issues/detail?id=385515
https://code.google.com/p/skia/issues/detail?id=3770

We are planning to replace SkImageDecoder with SkCodec,
and SkCodec will use the higher quality settings.  As
a first step, we are using SkCodec as the underlying
implementation for BitmapRegionDecoder.  CTS tests require
that BitmapRegionDecoder be a close match to BitmapFactory
(which uses SkImageDecoder), so we must also update the
quality of SkImageDecoder.

BUG=skia:
==========

to

==========
Change quality settings on SkImageDecoder_libjpeg

It has been demonstrated that higher quality settings
really do make a difference in the visual quality of
the output image.
https://code.google.com/p/chromium/issues/detail?id=385515
https://code.google.com/p/skia/issues/detail?id=3770

We are planning to replace SkImageDecoder with SkCodec,
and SkCodec will use the higher quality settings.  As
a first step, we are using SkCodec as the underlying
implementation for BitmapRegionDecoder.  CTS tests require
that BitmapRegionDecoder be a close match to BitmapFactory
(which uses SkImageDecoder), so we must also update the
quality of SkImageDecoder.

BUG=skia:
==========

[msarett, 2015-11-06 00:11:52]

Description was changed from

==========
Change quality settings on SkImageDecoder_libjpeg

It has been demonstrated that higher quality settings
really do make a difference in the visual quality of
the output image.
https://code.google.com/p/chromium/issues/detail?id=385515
https://code.google.com/p/skia/issues/detail?id=3770

We are planning to replace SkImageDecoder with SkCodec,
and SkCodec will use the higher quality settings.  As
a first step, we are using SkCodec as the underlying
implementation for BitmapRegionDecoder.  CTS tests require
that BitmapRegionDecoder be a close match to BitmapFactory
(which uses SkImageDecoder), so we must also update the
quality of SkImageDecoder.

BUG=skia:
==========

to

==========
Change quality settings on SkImageDecoder_libjpeg

It has been demonstrated that higher quality settings
really do make a difference in the visual quality of
the output image.
https://code.google.com/p/chromium/issues/detail?id=385515
https://code.google.com/p/skia/issues/detail?id=3770

We are planning to replace SkImageDecoder with SkCodec,
and SkCodec will use the higher quality settings.  As
a first step, we are using SkCodec as the underlying
implementation for BitmapRegionDecoder.  CTS tests require
that BitmapRegionDecoder be a close match to BitmapFactory
(which uses SkImageDecoder), so we must also update the
quality of SkImageDecoder to maintain CTS compatibility.

BUG=skia:
==========

[msarett, 2015-11-06 00:23:19]

Patchset #1 (id:1) has been deleted

[msarett, 2015-11-06 00:25:02]

Patchset #1 (id:20001) has been deleted

[msarett, 2015-11-06 00:28:01]

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

[msarett, 2015-11-06 00:28:02]

https://codereview.chromium.org/1412803009/diff/40001/src/images/SkImageDecod...
File src/images/SkImageDecoder_libjpeg.cpp (left):

https://codereview.chromium.org/1412803009/diff/40001/src/images/SkImageDecod...
src/images/SkImageDecoder_libjpeg.cpp:398: cinfo->do_block_smoothing = 0;
This setting is ignored by libjpeg/libjpeg-turbo unless we are decoding
progressive images using a buffered approach (which we are not).

[scroggo, 2015-11-06 18:49:35]

lgtm

[msarett, 2015-11-06 18:50:01]

This will need to land before:
https://googleplex-android-review.git.corp.google.com/#/c/803942/

So that we are able to pass the BRD tests.

[msarett, 2015-11-06 18:50:17]

The CQ bit was checked by msarett@google.com

[commit-bot: I haz the power, 2015-11-06 18:50:24]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1412803009/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1412803009/40001

[commit-bot: I haz the power, 2015-11-06 19:02:09]

Committed patchset #1 (id:40001) as
https://skia.googlesource.com/skia/+/69ad6a9d03dd6f14b7c730465319313725a7c903

[fmalita_google_do_not_use, 2015-11-09 00:29:49]

A revert of this CL (patchset #1 id:40001) has been created in
https://codereview.chromium.org/1432863002/ by fmalita@google.com.

The reason for reverting is: Valgrind failures:
http://build.chromium.org/p/client.skia/builders/Test-Ubuntu-GCC-GCE-CPU-AVX2...


==14022== Conditional jump or move depends on uninitialised value(s)
==14022==    at 0x6A1DD6: S32A_Opaque_BlitRow32_SSE4(unsigned int*, unsigned int
const*, int, unsigned int) (SkBlitRow_opts_SSE4.cpp:47)
==14022==    by 0x5A7EEA: Sprite_D32_S32::blitRect(int, int, int, int)
(SkSpriteBlitter_ARGB32.cpp:47)
==14022==    by 0x57DD8A: SkScan::FillIRect(SkIRect const&, SkRegion const*,
SkBlitter*) (SkScan.cpp:15)
==14022==    by 0x57DEDC: SkScan::FillIRect(SkIRect const&, SkRasterClip const&,
SkBlitter*) (SkScan.cpp:73)
==14022==    by 0x536072: SkDraw::drawBitmap(SkBitmap const&, SkMatrix const&,
SkRect const*, SkPaint const&) const (SkDraw.cpp:1286)
==14022==    by 0x59CC50: SkBitmapDevice::drawBitmap(SkDraw const&, SkBitmap
const&, SkMatrix const&, SkPaint const&) (SkBitmapDevice.cpp:248)
==14022==    by 0x52F0DC: SkBaseDevice::drawImage(SkDraw const&, SkImage const*,
float, float, SkPaint const&) (SkDevice.cpp:150)
==14022==    by 0x525139: SkCanvas::onDrawImage(SkImage const*, float, float,
SkPaint const*) (SkCanvas.cpp:2180)
==14022==    by 0x5279A0: SkCanvas::drawImage(SkImage const*, float, float,
SkPaint const*) (SkCanvas.cpp:1864)
==14022==    by 0x441C83: SKPBench::onPerCanvasPostDraw(SkCanvas*)
(SKPBench.cpp:95)
==14022==    by 0x40A3FF: Benchmark::perCanvasPostDraw(SkCanvas*)
(Benchmark.cpp:53)
==14022==    by 0x44C527: nanobench_main() (nanobench.cpp:1254)
==14022==    by 0x44D1E6: main (nanobench.cpp:1344)
==14022==  Uninitialised value was created by a heap allocation
==14022==    at 0x4C2AB80: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14022==    by 0x602DAC: chromium_jpeg_get_large (jmemnobs.c:57)
==14022==    by 0x602818: alloc_large (jmemmgr.c:376)
==14022==    by 0x602A2E: alloc_sarray (jmemmgr.c:453)
==14022==    by 0x614983: chromium_jinit_d_main_controller (jdmainct.c:450)
==14022==    by 0x5FD3A0: chromium_jinit_master_decompress (jdmaster.c:577)
==14022==    by 0x5F9198: chromium_jpeg_start_decompress (jdapistd.c:46)
==14022==    by 0x680C22: SkJPEGImageDecoder::onDecode(SkStream*, SkBitmap*,
SkImageDecoder::Mode) (SkImageDecoder_libjpeg.cpp:575)
==14022==    by 0x67BCE8: SkImageDecoder::decode(SkStream*, SkBitmap*,
SkColorType, SkImageDecoder::Mode) (SkImageDecoder.cpp:138)
==14022==    by 0x6845E3: SkImageDecoderGenerator::onGetPixels(SkImageInfo
const&, void*, unsigned long, unsigned int*, int*)
(SkImageGenerator_skia.cpp:59)
==14022==    by 0x53D4C7: SkImageGenerator::getPixels(SkImageInfo const&, void*,
unsigned long, unsigned int*, int*) (SkImageGenerator.cpp:40)
==14022==    by 0x53D6DF: SkImageGenerator::tryGenerateBitmap(SkBitmap*,
SkImageInfo const*, SkBitmap::Allocator*) (SkImageGenerator.cpp:179)
==14022==    by 0x53D334: SkImageCacherator::generateBitmap(SkBitmap*)
(SkImageGenerator.h:174)
==14022==    by 0x53D3A1: SkImageCacherator::tryLockAsBitmap(SkBitmap*, SkImage
const*) (SkImageCacherator.cpp:118)
==14022==    by 0x53D3EA: SkImageCacherator::lockAsBitmap(SkBitmap*, SkImage
const*) (SkImageCacherator.cpp:132)
==14022==    by 0x58EDCF: SkImage_Generator::getROPixels(SkBitmap*) const
(SkImage_Generator.cpp:59)
==14022==    by 0x52F007: SkBaseDevice::drawImageRect(SkDraw const&, SkImage
const*, SkRect const*, SkRect const&, SkPaint const&,
SkCanvas::SrcRectConstraint) (SkDevice.cpp:159)
==14022==    by 0x5255E0: SkCanvas::onDrawImageRect(SkImage const*, SkRect
const*, SkRect const&, SkPaint const*, SkCanvas::SrcRectConstraint)
(SkCanvas.cpp:2209)
==14022==    by 0x5279DC: SkCanvas::drawImageRect(SkImage const*, SkRect const&,
SkRect const&, SkPaint const*, SkCanvas::SrcRectConstraint) (SkCanvas.cpp:1872)
.

[mtklein, 2015-11-09 15:04:15]

On 2015/11/09 at 00:29:49, fmalita wrote:
> A revert of this CL (patchset #1 id:40001) has been created in
https://codereview.chromium.org/1432863002/ by fmalita@google.com.
> 
> The reason for reverting is: Valgrind failures:
http://build.chromium.org/p/client.skia/builders/Test-Ubuntu-GCC-GCE-CPU-AVX2...
> 
> 
> ==14022== Conditional jump or move depends on uninitialised value(s)
> ==14022==    at 0x6A1DD6: S32A_Opaque_BlitRow32_SSE4(unsigned int*, unsigned
int const*, int, unsigned int) (SkBlitRow_opts_SSE4.cpp:47)
> ==14022==    by 0x5A7EEA: Sprite_D32_S32::blitRect(int, int, int, int)
(SkSpriteBlitter_ARGB32.cpp:47)
> ==14022==    by 0x57DD8A: SkScan::FillIRect(SkIRect const&, SkRegion const*,
SkBlitter*) (SkScan.cpp:15)
> ==14022==    by 0x57DEDC: SkScan::FillIRect(SkIRect const&, SkRasterClip
const&, SkBlitter*) (SkScan.cpp:73)
> ==14022==    by 0x536072: SkDraw::drawBitmap(SkBitmap const&, SkMatrix const&,
SkRect const*, SkPaint const&) const (SkDraw.cpp:1286)
> ==14022==    by 0x59CC50: SkBitmapDevice::drawBitmap(SkDraw const&, SkBitmap
const&, SkMatrix const&, SkPaint const&) (SkBitmapDevice.cpp:248)
> ==14022==    by 0x52F0DC: SkBaseDevice::drawImage(SkDraw const&, SkImage
const*, float, float, SkPaint const&) (SkDevice.cpp:150)
> ==14022==    by 0x525139: SkCanvas::onDrawImage(SkImage const*, float, float,
SkPaint const*) (SkCanvas.cpp:2180)
> ==14022==    by 0x5279A0: SkCanvas::drawImage(SkImage const*, float, float,
SkPaint const*) (SkCanvas.cpp:1864)
> ==14022==    by 0x441C83: SKPBench::onPerCanvasPostDraw(SkCanvas*)
(SKPBench.cpp:95)
> ==14022==    by 0x40A3FF: Benchmark::perCanvasPostDraw(SkCanvas*)
(Benchmark.cpp:53)
> ==14022==    by 0x44C527: nanobench_main() (nanobench.cpp:1254)
> ==14022==    by 0x44D1E6: main (nanobench.cpp:1344)
> ==14022==  Uninitialised value was created by a heap allocation
> ==14022==    at 0x4C2AB80: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==14022==    by 0x602DAC: chromium_jpeg_get_large (jmemnobs.c:57)
> ==14022==    by 0x602818: alloc_large (jmemmgr.c:376)
> ==14022==    by 0x602A2E: alloc_sarray (jmemmgr.c:453)
> ==14022==    by 0x614983: chromium_jinit_d_main_controller (jdmainct.c:450)
> ==14022==    by 0x5FD3A0: chromium_jinit_master_decompress (jdmaster.c:577)
> ==14022==    by 0x5F9198: chromium_jpeg_start_decompress (jdapistd.c:46)
> ==14022==    by 0x680C22: SkJPEGImageDecoder::onDecode(SkStream*, SkBitmap*,
SkImageDecoder::Mode) (SkImageDecoder_libjpeg.cpp:575)
> ==14022==    by 0x67BCE8: SkImageDecoder::decode(SkStream*, SkBitmap*,
SkColorType, SkImageDecoder::Mode) (SkImageDecoder.cpp:138)
> ==14022==    by 0x6845E3: SkImageDecoderGenerator::onGetPixels(SkImageInfo
const&, void*, unsigned long, unsigned int*, int*)
(SkImageGenerator_skia.cpp:59)
> ==14022==    by 0x53D4C7: SkImageGenerator::getPixels(SkImageInfo const&,
void*, unsigned long, unsigned int*, int*) (SkImageGenerator.cpp:40)
> ==14022==    by 0x53D6DF: SkImageGenerator::tryGenerateBitmap(SkBitmap*,
SkImageInfo const*, SkBitmap::Allocator*) (SkImageGenerator.cpp:179)
> ==14022==    by 0x53D334: SkImageCacherator::generateBitmap(SkBitmap*)
(SkImageGenerator.h:174)
> ==14022==    by 0x53D3A1: SkImageCacherator::tryLockAsBitmap(SkBitmap*,
SkImage const*) (SkImageCacherator.cpp:118)
> ==14022==    by 0x53D3EA: SkImageCacherator::lockAsBitmap(SkBitmap*, SkImage
const*) (SkImageCacherator.cpp:132)
> ==14022==    by 0x58EDCF: SkImage_Generator::getROPixels(SkBitmap*) const
(SkImage_Generator.cpp:59)
> ==14022==    by 0x52F007: SkBaseDevice::drawImageRect(SkDraw const&, SkImage
const*, SkRect const*, SkRect const&, SkPaint const&,
SkCanvas::SrcRectConstraint) (SkDevice.cpp:159)
> ==14022==    by 0x5255E0: SkCanvas::onDrawImageRect(SkImage const*, SkRect
const*, SkRect const&, SkPaint const*, SkCanvas::SrcRectConstraint)
(SkCanvas.cpp:2209)
> ==14022==    by 0x5279DC: SkCanvas::drawImageRect(SkImage const*, SkRect
const&, SkRect const&, SkPaint const*, SkCanvas::SrcRectConstraint)
(SkCanvas.cpp:1872)
> .

That's a path where we're doing (src over dst) with full coverage, using SSE4.1
instructions to check each run of 16 pixels for two special cases: all fully
transparent (noop) or all fully opaque (copy without blending).  If we get this
error here or at line 42 (and I'm surprised it didn't report line 42 first) that
means the src pixels are uninitialized.

[msarett, 2015-11-09 15:24:06]

I've been able to reproduce the error and verify that reverting this CL fixes
the problem.

I still need to figure out what's going on though.

[msarett, 2015-11-09 16:53:20]

After pulling the jpegs from the skp, it looks like SkJpegCodec and
SkImageDecoder_libjpeg both have this same problem when do_fancy_upsampling is
turned on.

That could indicate that this is a bug in libjpeg-turbo.

[msarett, 2015-11-09 23:43:13]

Observations:

(1) This only occurs when doing fancy upsampling.
(2) This does not occur when SIMD is turned off.  (I have reproduced this with
x86_64 SIMD.)
(3) This has no effect on the output image.  I've initialized the memory with
all 0s and all FFs and seen all zero diffs.
(4) If I initialize one extra JSAMPLE in the x-direction, valgrind is happy.

Possibilities:
(1) libjpeg-turbo's jsimd_h2v2_fancy_upsample_sse2() has an error that rarely
comes up and rarely/never affects the final output.
(2) Valgrind is wrong.

Either way, I think poring over assembly code is longer a good use of time. 
I'll probably file a bug, I'm not sure this is relevant to fix right now.

This is actually the second strange valgrind/assembly error I've come across in
libjpeg-turbo.  The first one was magically fixed by using an older version of
libjpeg-turbo.

Two Problems with Not Fixing:
(1) BitmapRegionDecoder CTS tests will fail in Android because BRD is "too
different" from BitmapFactory (lower quality).
(2) If we still test on this skp when we replace SkImageDecoder with SkCodec,
this error will come back.

[scroggo, 2015-11-09 23:57:02]

On 2015/11/09 23:43:13, msarett wrote:
> Observations:
> 
> (1) This only occurs when doing fancy upsampling.
> (2) This does not occur when SIMD is turned off.  (I have reproduced this with
> x86_64 SIMD.)
> (3) This has no effect on the output image.  I've initialized the memory with
> all 0s and all FFs and seen all zero diffs.
> (4) If I initialize one extra JSAMPLE in the x-direction, valgrind is happy.
> 
> Possibilities:
> (1) libjpeg-turbo's jsimd_h2v2_fancy_upsample_sse2() has an error that rarely
> comes up and rarely/never affects the final output.
> (2) Valgrind is wrong.
> 
> Either way, I think poring over assembly code is longer a good use of time. 
> I'll probably file a bug, I'm not sure this is relevant to fix right now.
> 
> This is actually the second strange valgrind/assembly error I've come across
in
> libjpeg-turbo.  The first one was magically fixed by using an older version of
> libjpeg-turbo.
> 
> Two Problems with Not Fixing:
> (1) BitmapRegionDecoder CTS tests will fail in Android because BRD is "too
> different" from BitmapFactory (lower quality).
> (2) If we still test on this skp when we replace SkImageDecoder with SkCodec,
> this error will come back.

I recommend the following:
1) file a bug in Skia
2) file a bug with libjpeg-turbo (it will probably help if you can repro without
using Skia)
3) create a valgrind suppression and reland

[msarett, 2015-11-10 14:13:11]

Description was changed from

==========
Change quality settings on SkImageDecoder_libjpeg

It has been demonstrated that higher quality settings
really do make a difference in the visual quality of
the output image.
https://code.google.com/p/chromium/issues/detail?id=385515
https://code.google.com/p/skia/issues/detail?id=3770

We are planning to replace SkImageDecoder with SkCodec,
and SkCodec will use the higher quality settings.  As
a first step, we are using SkCodec as the underlying
implementation for BitmapRegionDecoder.  CTS tests require
that BitmapRegionDecoder be a close match to BitmapFactory
(which uses SkImageDecoder), so we must also update the
quality of SkImageDecoder to maintain CTS compatibility.

BUG=skia:

Committed:
https://skia.googlesource.com/skia/+/69ad6a9d03dd6f14b7c730465319313725a7c903
==========

to

==========
Change quality settings on SkImageDecoder_libjpeg

It has been demonstrated that higher quality settings
really do make a difference in the visual quality of
the output image.
https://code.google.com/p/chromium/issues/detail?id=385515
https://code.google.com/p/skia/issues/detail?id=3770

We are planning to replace SkImageDecoder with SkCodec,
and SkCodec will use the higher quality settings.  As
a first step, we are using SkCodec as the underlying
implementation for BitmapRegionDecoder.  CTS tests require
that BitmapRegionDecoder be a close match to BitmapFactory
(which uses SkImageDecoder), so we must also update the
quality of SkImageDecoder to maintain CTS compatibility.

BUG=skia:

Committed:
https://skia.googlesource.com/skia/+/69ad6a9d03dd6f14b7c730465319313725a7c903
==========

[msarett, 2015-11-10 14:44:43]

PTAL

Added suppressions.

[scroggo, 2015-11-10 21:24:40]

lgtm

https://codereview.chromium.org/1412803009/diff/60001/tools/valgrind.supp
File tools/valgrind.supp (right):

https://codereview.chromium.org/1412803009/diff/60001/tools/valgrind.supp#new...
tools/valgrind.supp:257: libjpeg_turbo_bug4550_2
Does valgrind need us to include every single line here? It seems like the stack
resulting in this draw could change, making the suppression ineffective

[msarett, 2015-11-10 21:34:14]

https://codereview.chromium.org/1412803009/diff/60001/tools/valgrind.supp
File tools/valgrind.supp (right):

https://codereview.chromium.org/1412803009/diff/60001/tools/valgrind.supp#new...
tools/valgrind.supp:257: libjpeg_turbo_bug4550_2
On 2015/11/10 21:24:40, scroggo wrote:
> Does valgrind need us to include every single line here? It seems like the
stack
> resulting in this draw could change, making the suppression ineffective

We don't need this much detail to suppress the errors.

It was actually intentional to make these suppressions very specific.  Because
they make me a little nervous.  There are no references to libjpeg-turbo in the
stack trace, just to drawing code.  I'd hate to suppress actual errors in our
drawing code because libjpeg-turbo has a problem.

Of course, you also make a good point.  However, if the stack trace does change,
it may give us a nice reminder to fix these :).

[msarett, 2015-11-11 14:07:50]

The CQ bit was checked by msarett@google.com

[commit-bot: I haz the power, 2015-11-11 14:08:03]

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

[commit-bot: I haz the power, 2015-11-11 14:08:53]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-11-11 14:08:54]

Try jobs failed on following builders:
  Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Debug-Trybot on client.skia (JOB_FAILED,
http://build.chromium.org/p/client.skia/builders/Test-Ubuntu-GCC-GCE-CPU-AVX2...)
  Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-Shared-Trybot on client.skia
(JOB_FAILED,
http://build.chromium.org/p/client.skia/builders/Test-Ubuntu-GCC-GCE-CPU-AVX2...)
  Build-Ubuntu-Clang-x86_64-Debug-Trybot on client.skia.compile (JOB_FAILED,
http://build.chromium.org/p/client.skia.compile/builders/Build-Ubuntu-Clang-x...)
  Build-Ubuntu-GCC-Arm64-Debug-Android-Trybot on client.skia.compile
(JOB_FAILED,
http://build.chromium.org/p/client.skia.compile/builders/Build-Ubuntu-GCC-Arm...)
  Build-Ubuntu-GCC-Arm7-Debug-Android-Trybot on client.skia.compile (JOB_FAILED,
http://build.chromium.org/p/client.skia.compile/builders/Build-Ubuntu-GCC-Arm...)
  Build-Ubuntu-GCC-Mips-Debug-Android-Trybot on client.skia.compile (JOB_FAILED,
http://build.chromium.org/p/client.skia.compile/builders/Build-Ubuntu-GCC-Mip...)
  Build-Ubuntu-GCC-x86_64-Release-Trybot on client.skia.compile (JOB_FAILED,
http://build.chromium.org/p/client.skia.compile/builders/Build-Ubuntu-GCC-x86...)

[msarett, 2015-11-11 14:29:30]

The CQ bit was checked by msarett@google.com

[msarett, 2015-11-11 14:29:31]

The patchset sent to the CQ was uploaded after l-g-t-m from scroggo@google.com
Link to the patchset: https://codereview.chromium.org/1412803009/#ps80001
(title: "Merge")

[commit-bot: I haz the power, 2015-11-11 14:29:46]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1412803009/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1412803009/80001

[commit-bot: I haz the power, 2015-11-11 14:41:04]

Committed patchset #3 (id:80001) as
https://skia.googlesource.com/skia/+/b5213e69c599c4ca492bd43fd235d698891ce34c