Commit Graph

3 Commits

Author SHA1 Message Date
Solly Ross c802d93189 Make sure Pako always has enough room
Previously, we used a fixed chunkSize of 100KiB for Pako's output
buffer.  Using a hardcoded size caused issues, since Pako would assume
we wanted to use multiple chunks, and we didn't deal with this.  Now,
`Inflator#inflate()` takes a new `expected` argument, which indicates
the expected output size.  If this is bigger than the current chunkSize,
Inflator allocates a new output buffer that's big enough to hold the
output.

Fixes #531
2015-09-23 09:53:00 -04:00
Solly Ross d1800d0960 Avoid Creating Small Objects Frequently
Creating lots of small objects frequently can drastically decrease
performance.  This commit introduces three fixes which avoid this:

- Use a preallocated palette and indexed-to-rgb destination Typed Array
  (the destination typed array is currently allocated at `4 * width *
  height`).

- Inline `getTightCLength`, which returned a two-item array.

- Pass RGBX data directly in a Typed Array to the Display, which
  avoids an extra loop, and only creates a new Typed Array View,
  instead of a whole new ArrayBuffer.
2015-08-06 14:47:03 -04:00
Solly Ross 6940936ffc WIP: Switch to Pako for zlib
This commit introduces an alternate implementation of the zlib
decompressor based on Pako (https://github.com/nodeca/pako).
2015-08-06 14:47:03 -04:00