we (web engine): Experimental web browser project to understand the limits of Claude
2
fork

Configure Feed

Select the types of activity you want to include in your feed.

PNG encoder uses stored (uncompressed) DEFLATE blocks — output is uncompressed #197

open opened by pierrelf.com

Found while reviewing the headless e2e harness, which encodes screenshots via we_image::png::encode_png_rgba.

crates/image/src/png.rs:817 (zlib_compress_data) writes zlib-wrapped data using only stored DEFLATE blocks (type 00) — that is, raw bytes with a 5-byte LEN/NLEN header per 64KB chunk. The resulting file is roughly the same size as the raw RGBA buffer plus a few hundred bytes of headers.

Concretely, a 800x600 RGBA screenshot is ~1.92 MB on disk regardless of content (verified across 12 test screenshots — all were 1,920,813 bytes).

Impact#

  • Canvas toDataURL(\"image/png\") produces enormous output.
  • Any page that round-trips an image through canvas inflates network payload.
  • The e2e smoke artifacts directory bloats by ~20 MB per pass.

Acceptance#

zlib_compress_data (and therefore encode_png_rgba) emits at least fixed-Huffman compressed DEFLATE blocks (block type 01) — and ideally dynamic-Huffman with LZ77 back-references. A 800x600 mostly-white screenshot should be < 20 KB.

A regression test in we-image's test suite asserts the encoded size of a uniform-colour image is small (e.g. < 1% of raw size).

sign up or login to add to the discussion
Labels

None yet.

assignee

None yet.

Participants 1
AT URI
at://did:plc:meotu43t6usg4qdwzenk4s2t/sh.tangled.repo.issue/3mlyacigqdx2v