Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Firefox 157 will include JPEG XL by default on all platforms

groups.google.com

Post reply on HN
Print view View original

41–50 of 138 posts

Re: Firefox 157 will include JPEG XL by default on all platforms

#41

Post by phire »

Snafuh wrote: post #25
concinds wrote: post #5

With both Firefox and Chromium using jxl-rs (Rust-based), I wonder what Apple will do about the libjxl (C++) they already shipped. I know they're doing some memory-safety with Swift, but are they shipping any Rust in their platforms so far? I also wonder if anyone's done benchmark comparisons between both libs. -- Also, I was under the impression that after backtracking, Chromium was relying on Mozilla to come up wit…

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 help performance.

The other benefit of rust is that the stronger type system makes it easier to iterate and optimise without bugs creeping in. But once optimisations are implemented in rust, there isn’t that much pain to porting them back to c++, as long as someone cares enough to do so.

Re: Firefox 157 will include JPEG XL by default on all platforms

#42

Post by sb057 »

mananaysiempre wrote: post #19
odo1242 wrote: post #12

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…

> [JPEG XL can] display much larger images than AVIF can Does it do tiles? What about pyramids (i.e. precomputed downscaled images, think mipmaps)? Right now the state of the art for truly large images (medical, geospatial, scanned artworks) seems to be JPEG (and I think also JPEG 2000?) tiles in TIFF containers, which would be fine except nobody seems to agree on how exactly to express the pyramids.

Level 10 spec is 2^40 pixels, which is a ~1 million x ~1 million pixel square.

Re: Firefox 157 will include JPEG XL by default on all platforms

#43

Post by wongarsu »

concinds wrote: post #37
deadbunny wrote: post #28

Earlier quoted context omitted.

[flagged]

I don't see what this has to do with the topic, sorry.

Their point is that Apple is the Nintendo of computing. They don't care what others do, they just do their own thing. Which produces some great things and some stupid things. They also don't care whether you think what they are doing is great or stupid, they just continue doing their thing

Which then tracks back to the beginning of the thread: the correct answer to whether apple will adopt jxl-rs or keep libjxl is "who knows, no point trying to predict them". Which is not a value judgement

How you square all of that with the iPhone regularly copying features Android had for years is your decision. Might be a symptom of the same, might be that this all was an entirely inaccurate description of Apple

Re: Firefox 157 will include JPEG XL by default on all platforms

#44

Post by magicalist »

phire wrote: post #41
Snafuh wrote: post #25

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…

> As much as I enjoy rust, there is no reason why a c++ library can’t be optimised to match the rust implementation.

I don't think anyone is claiming that. I took the GP's point as what was desired was a "safe, performant, compact, and compatible JPEG XL decoder in Rust" and "performant" (as defined as the speed of the c++ version) was passed two months ago.

> 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 help performance.

Sure, and looking at the recent commit histories, the team is focusing on getting the rust version ready for this milestone for obvious reasons, and is less concerned about immediate parity in the c++ codebase.

Re: Firefox 157 will include JPEG XL by default on all platforms

#45

Post by _joel »

deadbunny wrote: post #28
llm_nerd wrote: post #22

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…

[flagged]

That useless strip could play lemmings and doom, it wasn't all bad

Re: Firefox 157 will include JPEG XL by default on all platforms

#46

Post by AlotOfReading »

rfgplk wrote: post #38
Snafuh wrote: post #25

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.

If he is one of the devs between both libraries, why is there a performance gap? Why not port the optimizations from one lib to the other? You can even create a pinned agent workflow that automatically translates optimizations between repos. Fairly trivial to implement actually.

Just because you can theoretically write equivalent code in both languages doesn't mean two idiomatic implementations in each language will be 1:1 with each other. I haven't looked at the code in question, but some examples of common differences:

A C++ program might do template metaprogramming at compile time and the same thing at runtime in Rust, or vice versa. The C++ version might use virtual functions that rust wouldn't use. The Rust version might simply give more optimization information to the backend. The C++ version might use fairly awful parts of the stdlib like iostreams or shared_ptr that rust simply implements better. Etc.

Or maybe they're just focused on the rust implementation as they should be.

Re: Firefox 157 will include JPEG XL by default on all platforms

#47

Post by hn92726819 »

phire wrote: post #41
Snafuh wrote: post #25

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…

I don't understand why anyone would continue working on the c++ project once the rust one started beating it in performance

Re: Firefox 157 will include JPEG XL by default on all platforms

#48

Post by mananaysiempre »

sb057 wrote: post #42
mananaysiempre wrote: post #19

Earlier quoted context omitted.

> [JPEG XL can] display much larger images than AVIF can Does it do tiles? What about pyramids (i.e. precomputed downscaled images, think mipmaps)? Right now the state of the art for truly large images (medical, geospatial, scanned artworks) seems to be JPEG (and I think also JPEG 2000?) tiles in TIFF containers, which would be fine except nobody seems to agree on how exactly to express the pyramids.

Level 10 spec is 2^40 pixels, which is a ~1 million x ~1 million pixel square.

I mean, a plain JPEG can tolerate up to I think 2^16 × 2^16 pixels, and already that you don’t really want to decode from a single unseekable bitstream with no index and no effort to improve locality of data required to fill a rectangular viewport. [ImageMagick’s display(1) is the best at tolerating huge JPEGs and even it, IIRC, conks out after 2^15 × 2^15.] You can allocate however many bits you want for the size, but beyond a few dozen megapixels you really need to do indexed independently-decodable tiles, and when the image is dozens of gigabytes after compression, you need a pyramid of pre-downscaled versions as well (1/4 + 1/16 + ... ≈ 33% overhead which is completely acceptable). Thus my question.

Re: Firefox 157 will include JPEG XL by default on all platforms

#50

Post by saagarjha »

concinds wrote: post #5

With both Firefox and Chromium using jxl-rs (Rust-based), I wonder what Apple will do about the libjxl (C++) they already shipped. I know they're doing some memory-safety with Swift, but are they shipping any Rust in their platforms so far? I also wonder if anyone's done benchmark comparisons between both libs. -- Also, I was under the impression that after backtracking, Chromium was relying on Mozilla to come up wit…

Shipping unsafe C++ is easier on Apple platforms than Rust. This seems unlikely to change anytime soon.
Post reply on HN