[Webkit-unassigned] [Bug 54256] Improve the compression of Canvas's toDataURL function

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=54256


Scott Graham <scottmg at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |scottmg at chromium.org




--- Comment #4 from Scott Graham <scottmg at chromium.org>  2011-07-06 12:15:19 PST ---
I get a similar size (7270) now on Ubuntu as of Chrome 13.0.782.41.

The Skia path goes through PNGImageEncoder::encode, which contains the following:

    // Optimize compression for speed.
    // The parameters are the same as what libpng uses by default for RGB and RGBA images, except:
    // - the zlib compression level is 3 instead of 6, to avoid the lazy Ziv-Lempel match searching;
    // - the delta filter is 1 ("sub") instead of 5 ("all"), to reduce the filter computations.
    // The zlib memory level (8) and strategy (Z_FILTERED) will be set inside libpng.
    //
    // Avoid the zlib strategies Z_HUFFMAN_ONLY or Z_RLE.
    // Although they are the fastest for poorly-compressible images (e.g. photographs),
    // they are very slow for highly-compressible images (e.g. text, drawings or business graphics).

It seems sensible to sacrifice base64 size in exchange for encoding speed for cases where the data url is passed directly back into an img tag or similar.

That said, I'm not sure what a good benchmark would be to decide whether the parameters used currently are a good tradeoff.

http://philip.html5.org/tests/canvas/misc/todataurl-args.html hints that adding extra args such as "compression=9" after the MIME type might make sense to influence the compression, but that'd be purely ad hoc.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.