81–90 of 140 posts
Earlier quoted context omitted.
It compresses better than webp*, has really good progressive decoding (current encoders are able to encode the image such that the most important part of the image gets decoded first, and you only need the first ~20% of the image to display it as a thumbnail), and it's also a very flexible format (unlike avif) since it can also display lossless files* and display much larger images than AVIF can. Also the compatibili…
of course these are all fairly controversial claims - people dispute it compresses meaningfully better the types of images typically found on the web. - progressive decoding is increasingly less useful on the internet as more and more connections become latency limited instead of bandwidth limited. jpeg & png (Although png's version has a cost i think) both support progressive decoding. However the last time i saw an…
Generally, the approach should always be to prioritize files loading as fast as possible.
Earlier quoted context omitted.
Luca Versari, one of the devs between both libraries, has a performance dashboard to compare performance between the two https://jxl-rs-perf.lucaversari.it/ jxl-rs started to outperform the C++ library 2 months ago.
As much as I enjoy rust, there is no reason why a c++ library can’t be optimised to match the rust implementation. It’s very rare that the actual performance benefits of rust implementations come from rust itself (though it does often push you to slightly better patterns). They usually come from the fact that rust implementations are usually a second (or 3rd, or 4th) iteration of the design, and the lessons learned h…
Earlier quoted context omitted.
I have only heard of it in passing. I wonder what it adds beyond Webp and Avif.
At the basic job of showing a normal 24bpp photo on screen, the differences between the formats are marginal. jxl shines when you want to do anything even a little bit more complex. Support for lots more color formats, including fp ones. Support for an image with parts of it encoded losslessly, and parts with a lossy encoder. Great progressive decoding. And many more features.
Earlier quoted context omitted.
What a funny tangent to go off on. JXL was dead. Apple is who brought it back to life[1], and the only reason Chrome resurrected JXL, and now Firefox followed their path, is because Apple pushed JXL support to a billion plus devices. I know people like complaining about Apple, but there's a "read the room" kind of moment where people just seem to either not know the context or are just knee jerking. [1] Worth noting…
> JXL was dead. Apple is who brought it back to life No, it was actually the PDF Association. They added JXL to the PDF standard. If google wanted to maintain support for displaying PDFs, they would need to add support for JXL.
> No, it was actually the PDF Association.
The PDF Association didn't adopt JPEG-XL until September 2025. By then, Apple had been shipping JPEG-XL in Safari for two years [1]. So there's that.
[1]: https://webkit.org/blog/14205/news-from-wwdc23-webkit-featur...
Earlier quoted context omitted.
Hasn't been the case for some time.
Not true. MacOS releases a new version each year, the current MacOS landscape looks like: - MacOS Sequoia (previous version, everything works as expected) - MacOS Tahoe (current version, broken experience, basically Apple's "Windows Vista/8 moment") - MacOS Golden Gate (next version, fixes what was broken in Tahoe, comes out in a month) I'm on MacOS Sequoia because I have things that can't be broken by updating to Ta…
You can download three Linux-compatible WebKit-based browsers from Apple's WebKit page:
Epiphany Technology Preview: https://webkitgtk.org/epiphany-tech-preview
WPE: http://wpewebkit.org/download
WebKitGTK: http://webkitgtk.org/download
Earlier quoted context omitted.
of course these are all fairly controversial claims - people dispute it compresses meaningfully better the types of images typically found on the web. - progressive decoding is increasingly less useful on the internet as more and more connections become latency limited instead of bandwidth limited. jpeg & png (Although png's version has a cost i think) both support progressive decoding. However the last time i saw an…
Disagree with the second point. For one, there are many parts of the world where bandwidth still is an issue, either due to lack of infrastructure or because common people in those places can't afford better connections. This isn't going to change any time soon because although given bandwidth goes up over time, so do the file sizes websites serve. And even then, I'm posting this through a super fast connection, with…
Earlier quoted context omitted.
Is it? I wrote a pure rust iOS app recently. It uses native controls, and looks and feels great. iOS and iOS-sim are both very well supported targets by the rust compiler.
You’re not shipping code as part of Safari
> Shipping unsafe C++ is easier on Apple platforms than Rust.
... Which seems false.
I can easily believe that apple might not have rust tooling in their Safari build system. But that doesn't mean rust has poor support for apple platforms.
Earlier quoted context omitted.
The big feature over other new formats is compatibility with legacy JPEGs. You can (simplified) take the raw data from a legacy JPEG, reformat it as a JPEG XL, and achieve like 20-30% filesize savings without any actual re-encode, just better packaging of the same data. While converting them to AVIF or webp is a lossy re-encode, and so loses quality. I think it's really this feature that has people wanting it still d…
There are some other advantages, such as jxl being able to progressively load in web broswers, while avif can't for some reason. However avif compression seems to be better at low qualities, which might be relevant for some web applications, if one doesn't want to serve both jxl and avif. There's a good visual comparison here: https://www.youtube.com/watch?v=SzsM4HMKmEI
I haven't actually seen a progressive jpeg rendering since the dialup days at any rate.
> 'The etymology of the name "XL" is as follows: JPEG has called all its new standards since j2k something that starts with an X: XR, XT, XS (S for speed, since it is very fast and ultra-low-latency), and now XL. The L is supposed to mean Long term, since the goal is to make something that can replace the legacy JPEG and last as long as it did.'[1]