Also this line is expensive:

https://github.com/eugeneware/jpeg-js/blob/a2f7080781a5539c65c2b42927cae28f1f051be5/lib/decoder.js#L1079

We could allow the outside to pass in a UInt8Array and just use it.

The outside can pass an ArrayBuffer in which case the new UInt8Array will re-use the same memory, but the jpeg-js inner code does not know which range of data in the ArrayBuffer to use.

Thanks for filing @trusktr!

I'm not opposed to letting the user pass in a bufferlike object to use for writing the data out 👍 that seems fine but I definitely wouldn't want to make it required by default.

Use case: this is useful, for example, when processing frames of a live video feed, frame by frame as they stream in.

FWIW, I would strongly advise against trying to use jpeg-js for this. It's slower than pretty much every other option you have regardless of your environment. For this reason, I also don't really want to bend over backwards to make minor malloc optimizations when the decode itself is so slow, synchronous, and holding all pixels in memory anyway.

No prob!

I was going to try it in a separate thread. I found that an offscreen canvas in a worker, drawing images from a Blob of jpeg data works well. Still curious to try it out though. So when I do, I'll fork and make those small mods.

Also wanted to try it in WASM (in a worker). I've been hearing of WASM reaching speeds only negligibly slower than native in some cases lately. Looks like someone forked the decoder to AssemblyScript at some point: https://github.com/glovas/assemblyscript-jpeg-decoder