Hacker News new | ask | show | jobs
by woah 1105 days ago
Dumb question, but why is OS or browser support necessary? Couldn't an HTML canvas element and some JS that can parse the file format display any kind of image that you might want?
7 comments

On MacOS/iOS the ImageIO framework handles encoding and decoding images. Adding support for your image format to that framework means everything else just works once the image is decoded.

Another framework, CoreImage, provides generic operations to filter and transform images decoded by ImageIO. This provides hardware acceleration and other good stuff that make things like CSS transforms super fast and efficient.

While it can be done in JavaScript it would be much much slower, less efficient, and kill your battery.

There's a JS/WASM polyfill for JXL, but it involves some fragile hacks like MutationObserver and canvas writes, has worse performance than native code, and tends to crash Chrome.
Why would MutationObserver be necessary to display a static image in a <canvas>?
Yes, if you don't care for loading speed, battery life, and the fans blazing...
Canvas has hard caps on the size it can be as well and when resizing an image to a fixed size, there is a lot of hard edges as you need to implement your own smoothing. Image tag is more flexible and versatile.
HDR and progression are difficult to do right now. Possible interplay with CPU/GPU in rendering is difficult. JS is executed later than html is parsed.
A canvas element is not as performant as an image element.
When I am serious about images it is all about high performance: upgrading to better data compression (1) speeds up the network and server and reduces (2) network and (3) storage costs. (4) Decompression of the image is another bottleneck and a soft decoder is itself something to download and compile locally.

If you use a high-powered device you might not appreciate that performance of a low-end Android device hasn't really improved since 2017. I test with an Android Go device that does pretty well if you feed it scaled images but would struggle with the soft decoder.

The native implementation of the decompressor can be much better than one in WebAssembly in that it can use SIMD units on the CPU and many other tricks, including special purpose hardware. That's why Apple is so keen to say that an image format is now supported in the OS, because they codesign the hardware, the OS and the file formats to take advantage of all that.

Why down-mod this straightforward question?

Come on, people.