Tweak libpng encoding parameters to increase speed on very large images.

Tweak libpng encoding parameters to increase speed on very large images.

Trades off speed for size. If someone's using fast encoding, they
probably don't really care about optimizing for size anyway.

BUG=none

[dcheng, 2016-04-22 01:01:56]

Description was changed from

==========
Tweak libpng encoding parameters to increase speed on very large images.

Trades off speed for size. If someone's using fast encoding, they
probably don't really care about optimizing for size anyway.

TODO: Get more measurements on size effect.

BUG=
==========

to

==========
Tweak libpng encoding parameters to increase speed on very large images.

Trades off speed for size. If someone's using fast encoding, they
probably don't really care about optimizing for size anyway.

BUG=none
==========

[dcheng, 2016-04-22 01:07:18]

dcheng@chromium.org changed reviewers:
+ danakj@chromium.org, erg@chromium.org, kinuko@chromium.org

[dcheng, 2016-04-22 01:14:01]

Initial patch for comments.
+kinuko for //content
+erg for //ui/gfx/codec
+danakj for new dependency on //cc/debug

When profiling, I noticed that we spent a /lot/ of time in the PNG filtering
code. I figure that if we are optimizing for speed, we probably don't care about
filtering.

I'm less certain if PNG encoding with no compression is a good idea. This makes
image paste more likely to fail for large images (e.g. 8000x8000 images): sites
like imgur.com apparently try to create a String from the resulting blob...
which is going to be nearly 0.5GB of memory! It's also slower if the image is
very compressible.

(I'll post numbers from the perf tests in a bit, I have to run for now)

https://codereview.chromium.org/1874403003/diff/40001/ui/gfx/codec/png_codec.cc
File ui/gfx/codec/png_codec.cc (right):

https://codereview.chromium.org/1874403003/diff/40001/ui/gfx/codec/png_codec....
ui/gfx/codec/png_codec.cc:591: if (compression_level <= Z_BEST_SPEED)
Alternatively, I could add another parameter to DoLibPngWrite and
EncodeWithCompressionLevel. However, I felt like libpng's filter parameters are
kind of opaque and hard to understand, so I just hardcoded here: the idea is if
you are passing Z_BEST_SPEED, you probably want it to be as fast as possible.

[kinuko, 2016-04-22 01:38:19]

//content change lgtm (but if others are happy with the actual PNG encoding
change)

[danakj, 2016-04-22 20:29:46]

https://codereview.chromium.org/1874403003/diff/40001/ui/gfx/BUILD.gn
File ui/gfx/BUILD.gn (right):

https://codereview.chromium.org/1874403003/diff/40001/ui/gfx/BUILD.gn#newcode702
ui/gfx/BUILD.gn:702: "//cc",
Hmmm, I wish that LapTimer was in cc:test_support, but we use it for telemetry
tests which have support built into the binary.

LGTM I suppose for the dep.

[Elliot Glaysher, 2016-04-25 19:06:16]

I'd be a bit surprised if this is a net win. I wonder how *other* apps that
aren't chrome deal with large, uncompressed PNGs, and if there are any latent
bugs there.