Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mark Adler's reaction #6

GoogleCodeExporter opened this issue Mar 9, 2015 · 3 comments

Mark Adler's reaction #6

GoogleCodeExporter opened this issue Mar 9, 2015 · 3 comments


Copy link

Mark Adler who wrote Zlib with Mark Nelson just expressed its feelings about 
Zopfli on the [Zlib-devel] mailing list:
"That's cool, but it seems like an awful lot of effort for a small improvement. 
 Perhaps it's time to add a better compression method to HTTP's 

I can only agree, Deflate was written around 1994 (when operating systems like 
Windows 95 required 24MB of main memory and Unicode was a toddler), its 
definitely time to move on!
Even ZIP archives can handle better compression algorithms (Deflate64, bzip2, 
PPMD, LZMA) since years.
WebP has a search window that is way larger than Deflate (32k), HTML5 only 
recommends UTF-8 encoding and Deflate is still single byte oriented... imagine 
how poorly it performs on pages holding text written in Devanāgarī (3 bytes 
per Unicode code point in UTF-8, main script used by nearly half of the 
population in India).

Original issue reported on by on 3 Mar 2013 at 7:13

Copy link

This is missing the point. The point is that Zopfli is compatible with the 
existing deployed base of BILLIONS of clients. No new scheme would be. The 
original version of Chrome supported BZIP2 "just because" but it was pulled out 
after it was determined that it caused problems with intermediaries.

More interestingly, even though other algorithms (e.g. LZMA) generate smaller 
output, the new SPDY protocol (which doesn't require back-compat) is based on 
GZIP/DEFLATE, most likely for ease-of-porting and performance on low-spec CPUs. 

Original comment by on 7 Mar 2013 at 6:18

Copy link

The same goes for WebP vs PNG or JPEG, would you say to the folks behind it 
that it's a worthless effort since PNG and JPEG are already available in all 
the browsers?
Innovation will not stop because there's something already deployed at large 
scale and since years, the main problem is to move smoothly from something that 
has wide acceptance to something new.

Nowadays we have atrocities like the "data:" URL scheme (RFC2397) that's base64 
encoded binary files embedded in HTML or CSS files, Deflates knows nothing 
about base64 (advanced compressors decode the base64 data and reencode it that 
way during decompression) the best Deflate could do at this level is produce a 
block that would just fit the base64 part.

SPDY is not there to last as it will be replaced by HTTP/2, and HTTP header 
compression based on Deflate is no longer an option for HTTPS since it is 
subject to the "CRIME" security exploit.

Original comment by on 8 Mar 2013 at 12:52

Copy link

Acknowledged. Closing because it is not Zopfli specific.

Original comment by on 10 Jul 2014 at 3:10

  • Changed state: WontFix

kornelski pushed a commit to ImageOptim/zopfli that referenced this issue Dec 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

1 participant