Bug 51455 – [chromium] Reduce canvas.toDataURL("image/png") run-time costs 300%

• Component: Canvas
• Status: RESOLVED FIXED

[noel gordon]

Chrome win32 is 2 times slower than Mozilla 3.6.12 win32, and 3 times slower than
Safari 5.0.3 win32 in my testing when calling canvas.toDataURL("image/png").

[noel gordon]

Created attachment 77198 [details]
patch

[noel gordon]

Extraction results for 800 x 600 px test image, this to determine the compression level used by chromium with the default libpng compressor.

safari 5.0.3 win32 (baseline)
   x, extract image/png 167 ms length: 1171790 bytes

chrome 10 win32 dev, for compression levels [1-9]
   1, extract image/png 168 ms length: 1237066 bytes
   2, extract image/png 179 ms length: 1222386 bytes
   3, extract image/png 216 ms length: 1188118 bytes
   4, extract image/png 264 ms length: 1136778 bytes
   5, extract image/png 331 ms length: 1120050 bytes
   6, extract image/png 510 ms length: 1098442 bytes ** default
   7, extract image/png 623 ms length: 1091738 bytes
   8, extract image/png 890 ms length: 1087218 bytes
   9, extract image/png 929 ms length: 1086930 bytes

Conclusion: chrome uses the default compression level 6, and is noticeably slower
than Safari even though we both use libpng. For a compressed output size matching
Safari (compression level 3), chrome is still ~50% slower than Safari.

[noel gordon]

The alternative compression methods offered by libpng, namely, Z_RLE, Z_FILTERED,
and Z_HUFFMAN_ONLY, should then be considered.  Z_FILTERED is slower, and not as
compressive as Z_HUFFMAN_ONLY, Z_RLE.

Z_HUFFMAN_ONLY seems a good choice compared to Z_RLE - that latter runs about 2-10%
slower (see http://optipng.sourceforge.net/pngtech/z_rle) for similar compressed
output data size (http://optipng.sourceforge.net/pngtech/z_rle.html).

Does the libpng compression level alter the results when using Z_HUFFMAN_ONLY?  It
should not, but I varied the compression level from Z_BEST_SPEED (1) through to
maximal compression (9) to test: 

 huffman encoding (Z_HUFFMAN_ONLY) with compression levels [1-9] 

   1, extract image/png 156 ms length: 1204834 bytes 
   2, extract image/png 156 ms length: 1204834 bytes 
   3, extract image/png 156 ms length: 1204834 bytes
   4, extract image/png 164 ms length: 1204834 bytes
   5, extract image/png 168 ms length: 1204834 bytes
   6, extract image/png 166 ms length: 1204834 bytes
   7, extract image/png 166 ms length: 1204834 bytes
   8, extract image/png 167 ms length: 1204834 bytes
   9, extract image/png 166 ms length: 1204834 bytes

There was a consistent 10 ms increase in run-time cost for compression levels > 3.
Z_BEST_SPEED seems like a good choice.

[noel gordon]

Created attachment 77294 [details]
patch update changelog description

[Adam Barth]

Comment on attachment 77294 [details]
patch update changelog description

Sounds like a win to me.

[noel gordon]

Darin mentioned that this seems like something developers should be able to configure, and I concur.  As a developer, I can control jpeg compression quality, but not png compression quality :(

[WebKit Commit Bot]

Comment on attachment 77294 [details]
patch update changelog description

Clearing flags on attachment: 77294

Committed r74541: <http://trac.webkit.org/changeset/74541>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.