performance: make memory re-usable instead of allocating new memory for every image decoded

[trusktr]

Maybe it also applies to encoding too, but I just looked at the decoder code.

These lines:

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

If we allow the user to send in an ArrayBuffer, and as long as the size of it is big enough to fit the image data, then jpeg-js could simply write data to it.

This part will be 400% faster on the 2^nd...N^th invocations of decode() based on similar stuff I've done in other projects.

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

[trusktr]

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.

[patrickhulce]

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.

[trusktr]

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.

[trusktr]

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