Implement Image Resizing

CryZe commented 7 years ago

It generally doesn't make much sense too store super large images, so we re-encode them as JPEGS < 256x256 (while keeping the aspect ratio in mind).

CryZe commented 7 years ago

Okay, so there's 3 issues with this:

There's a massive overhead for the size of the library. At the time of implementation, it more than doubled the size of the library.
Due to the library size overhead and the image reencoding, the loading times are really bad.
Some decoders such as the jpeg decoder use threading for decoding, which panics on emscripten.

CryZe commented 6 years ago

Alright, so it looks like we could experiment with this again. The WASM build is already somewhat smaller than the emscripten build, and since WASM is also faster, shrinking the images shouldn't be that bad anymore. If it is still bad, then we could send the images over to a web worker that then scales them down and sends the shrunken images back to the main process. That's essentially equivalent to multi threading. I'm not entirely sure how we would do that though, as the web worker wouldn't really run livesplit-core and modifying the icons while they are being used in a Timer object isn't something livesplit-core supports at the moment.

Also we should probably start implementing this in the original LiveSplit first to really begin reducing the image size in splits that are "around in the wild", to reduce the performance burden for LSO. If almost all split files that are actively being used have scaled down images already, due to LiveSplit doing that, then LSO really only needs to scale the images in the Run Editor, which is much less of a problem.

CryZe commented 6 years ago

Alright, so looking at this again, the file size overhead increases the wasm file from ~1.5 MiB to ~2 MiB. Considering this is being sent as a compressed file, it's not that bad. It's still somewhat suboptimal. The file shrinking itself is not that slow and should long term only really apply to the Run Editor, so it's somewhat bearable. JPEG Decoding is still not working, but it seems like an easy fix and it doesn't seem to be straight up panicking anymore (at least on wasm-unknown).

CryZe commented 6 years ago

It looks like I never linked the JPEG Decoding issue here, so here it is: https://github.com/kaksmet/jpeg-decoder/issues/75

glacials commented 6 years ago

+1 to this, occasionally a Splits I/O user will have issues with parsing due to the sheer size of the images in the file. It also contributes to our need to budget so much memory for our servers.

LiveSplit / livesplit-core

Implement Image Resizing #47