* Add LTO for C++ builds
This didn't have much effect on fastcomp builds, but provides further size savings with new LLVM backend we switched to in #750 (and fixes the MozJPEG size regression from the same PR).
In the future we won't need to pass `--llvm-lto 1` explicitly, but latest Emscripten Docker image doesn't contain the Emscripten version with the necessary fixes for this.
* Delete build.log
Co-authored-by: Jake Archibald <jaffathecake@gmail.com>
We've been running each Make command in a single thread, resulting in fairly slow builds for C++ codecs.
This change instead runs all `make` invocations with `-j` defaulting to number of cores (retrieved via `nproc`).
On my machine Docker uses a VM configured to 4 cores out of 8 available. This change brings total build time for C++ codecs down from 10m28s to 7m5s (~3.5 minutes difference).
Note (1): I've converted imagequant builds to use built-in `make` as well to leverage this parallelisation and future-proof build script.
Note (2): we don't need to do the same for Rust, since Cargo parallelises builds by default.
Looks like we've been stuck on Emscripten fastcomp backend, misssing out on all new optimisations between LLVM 6 and LLVM 11 and going via slow asm.js pipeline when building.
This changes Docker images for Emscripten projects to point to emscripten-upstream instead and commits the updated artifacts.
This was a no-op in Wasm anyway. Now that I've added ability to control logging upstream, let's use it to disable it from compiled unit altogether for a slight win in size and perf.
This makes building simpler and allows us to potentially use multithreading version in the future.
For now points to a custom fork of OxiPNG that enables WebAssembly support, as PR is still pending review.
Benefits:
- newer versions of the libraries
- zlib: 1.2.8 -> 1.2.11
- libpng: 1.6.18beta04 -> 1.6.34
- much fewer dependencies to install (as libs are already in optipng archive and we don't need napa)
- much smaller build thanks to customised versions of zlib and libpng containing only APIs necessary for optipng itself: 238950 -> 177359 bytes
- much faster build thanks to preconfigured libpng and stripped APIs: 2m15s -> 40s
- much simpler build script: 77 -> 46 lines
This delegates loading of Wasm modules to Webpack itself, making wrapper code simpler.
Emscripten-generated modules are still using custom loading glue as they're not compatible with Webpack.
Nightly is no longer necessary for wee_alloc, so we don't need to rely on unstable versions of Rust anymore.
As a bonus, this reduces size of each Rust-related Docker image by >1 GB:
- `squoosh-rotate`: 2.94GB -> 1.87GB
- `squoosh-resize`: 3.09GB -> 2.02GB
- `squoosh-hqx`: 3.13GB -> 2.06GB
* Scaling works on native
* It works in wasm
* Integrate with UI
* Remove benchmark
* Integrate Hqx into Resizer module
* Link against repo for hqx
* Remove unused defaultOpts
* Re-add test file
* Adding size dropdown
* Chrome: go and sit on the naughty step
* Better docs
* Review
* Add link to crbug
* Update src/codecs/processor-worker/index.ts
Co-Authored-By: Jake Archibald <jaffathecake@gmail.com>
* Terminate worker inbetween resize jobs
* Add sRGB -> RGB conversion before resize
* Add clamping for color space conversions
* Clip for demultiplication as well
* Fixing linear <-> srgb conversion
* Update benchmark
* Decouple srgb calculations
* Generate lookup tables
* Update src/codecs/resize/options.tsx
* Defaulting on, renaming, removing redundant state
* Implement alpha premultiplication
* Add benchmark to resize
* Only display "Premultiply alpha" if it's one of the rust resize types.
* Add comment about division by zero
