@kornel what happened about that thing of building...

@kornel what happened about that thing of building native libraries to Wasm, then doing AOT compilation and running the resulting code in a sandbox that Firefox was supposed to be doing? Sounds like the perfect solution to to add support while avoiding directly using the C++ implementation, yet having a complete implementation today:

https://hacks.mozilla.org/2021/12/webassembly-and-back-again-fine-grained-sandboxing-in-firefox-95/

Saying “we want to support JPEG-XL but we won't until $X that somebody else had to do” sounds like moving goalposts in an attempt to silence the people asking for the feature without really committing to work on it.

Like 4 September at 17:06 | Wall-to-wall | Open on oldbytes.space

3 comments

Haelwenn /элвэн/ :triskell:

@aperezdc @kornel Which reminds me that I wonder how big a jpeg-xl decoder compiled to wasm would be, as if it's small enough webapps with a lot of images could probably use it and still save some bandwidth.

4 September at 17:20 | Open on queer.hacktivis.me

Jeff Muizelaar

@aperezdc @kornel WASM sandboxing has a performance cost (especially because of having a separate heap) that we don't really want for image decoding.

4 September at 17:42 | Open on hachyderm.io

Hovav Shacham

@jrmuizel @aperezdc @kornel Can you say a bit more about your performance targets? If SoundTouch (which has hard latency requirements) can be RLBoxed, I'm surprised that jxl can't!

4 September at 18:48 | Open on infosec.exchange