mastodon.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
The original server operated by the Mastodon gGmbH non-profit

Administered by:

Server stats:

380K
active users

daniel:// stenberg://

The current JPEG XL decoder in apparently consists of more than 100,000 lines of multi-threaded C++

For just decoding an image format.

Not sure what it says about the format, the implementation and the Internet at large.

github.com/mozilla/standards-p

GitHubFirefox will consider a Rust implementation of JPEG-XL by bholley · Pull Request #1064 · mozilla/standards-positionsBy bholley

@bagder or about C++ and the state of coding and programming language tooling...

@bagder (i will keep banging the drums that most of the FOSS "supply chain" fear could be handled by investing more in programming language tooling, as Rust demonstrate, and that it would be a small overall cost for massive pay off...)

@Di4na possibly: I believe Rust is generally a good thing for most things, but I believe the Rust ecosystem with cargo and bazillions of always-updatiing tiny dependencies risk adding friction and at least complicates the equation quite a lot

@bagder This is my biggest worry too: they essentially copied the NPM package management model and practices. Good for short term productivity, but I worry that it causes significant long-term maintainability problems.

And everything is version 0.x, in part due to technical limitations of Cargo: moving out of 0.x is a breaking change, so if you have users on 0.x (which Cargo encourages by adding semver compatibility rules which make 0.x.a compatible with 0.x.b), moving out of 0.x breaks them.

@RichiH @deltablot

It was for a long time, but they released 1.0.0 in 2021 and have had a number of 1.0.x releases since then.

crates.io/crates/semver/versio

Also, releasing a 1.0 of a crate does not "break" anything that uses an older version.

@mort @bagder

crates.iocrates.io: Rust Package Registry

@mort @bagder I agree. I can say the same about Nuget for .Net. It seem a trend that people follow blindly.

@mort @bagder So they copied the worst feature of Go's package versioning? Yeesh.

@bagder @Di4na
I'm not sure it is a tooling issue. I find cargo to be a great tool, and it have a lock file to let you update deps in a controlled fashion.
I think this comes down to a cultural issue, where the rust community, much like the JS community, put every little utility function in it's own library. Hence, you tend to get a gazillion small dependencies that is hard to keep track of.

@bagder @Di4na
Cargo is of course good att handling these kinds of small dependencies, so in that way it is contributing to this culture.

@snaggen @bagder @Di4na there's one tooling issue: cargo tree should not only show you all transitive dependencies, but also have a mode to show you does grouped by author-group. That way even if, say, tokio is actually comprised of 10 crates, you can see that you're relying on one group that decides to split their codebase (for easier reuse, compile times, organization, etc.), instead of 10 different groups of people.

@ekuber @snaggen @bagder yeah. Or you could realise that nearly all your fundamental deps are maintained by one person trying to juggle it all

@snaggen @bagder @Di4na If you have tools supporting complex chains of small dependencies, you get complex chains of small dependencies.

@bagder i mean yes, but at least the compiler is a tool.

While C and others are uh. Well some are finally realising they have users

@Di4na @bagder the lack of a (standardized) package manager in C and C++ makes it such that the culture writes software that minimizes dependencies. Writing a library that depends on boost, the most popular well established C++ library of all time, is an asshole move, because now I have to figure out where the header files go, and how my build system links this dll/so/lib/a/dynlib and oops I built that with a different compiler ABI break. So people don't, and there are serious benefits

@MoBlack @bagder TBF writing software in C or C++ is itself an asshole move, because now i need to deal with build systems that never left the 20th century.

@bagder That sounds like an atrocity. But if it shows ads faster...uhm...nevermind.😌

@pkal @bagder Better compression rates for lower-fidelity lossy images. AVIF is horrible IMHO for lossless for example.

@bagder yeah, kinda puts into perspective all the 'negative feedback' the Chrome team received for removing JPEG-XL support. I wouldn't want to have such a monstrosity in my code base either, no matter what advantages the actual encoding might have over existing formats.

@floooh @bagder The alternative current file formats incorporate full video codecs. They are not smaller.

@floooh @dascandy @bagder A reference impl that reads untrusted input and then mallocs as much as it says too isn't going to get far...

@freddy ... and that happens to be the one Firefox uses...

@bagder Well, it seems that your point is "Firefox consists of bad code", whereas I believe that the conclusion from the post should be "The library is bad code, which is why we are not using it in production. We'd be happy to look at their rust implementation, when it's possible"

(footnote: "bad code" being an abbreviation of "100k multi-threaded C++")

@freddy you're reading too much into my words. I'm just amazed by how large the existing JPEG XL decoder is.

And I don't think I am alone.

@bagder Oh, OK. Sorry for misreading then. I'll back off. 🙂

(And yes, the existing library is... 🤯)

@freddy @bagder At least it is not false advertising, XL is in the name after all.

@freddy @bagder
> (footnote: "bad code" being an abbreviation of "100k multi-threaded C++")

"bad" is relative. What do the other current file formats look like?

I know PNG, TIFF and BMP are smaller. Some not even by that much when fully implemented. But there's a reason you don't want to use those.

HEIF and AVIF are in no way simpler or smaller. Heck, I'd expect them to have a larger code base.

@dascandy @bagder others are worse. But that shouldn't forbid us to raise the standards of what is considered acceptable :)

@freddy @bagder The question is do you want simple implementations or compact file formats?

Right now we're going more towards compact file formats, which goes away from simple implementations.

@dascandy @bagder We've already bitten the bullet with stuff like libwebp, where there's essentially only one implementation where ONE security bug affected basically all interesting end user software out there (arstechnica.com/security/2023/) and that's something we will need to live with for enduring support of the web until there's something better. Doesn't mean we should accept that for new formats. I believe, the compact files/simple implementations is a false dichotomy here. Rust can solve this

Ars Technica · Incomplete disclosures by Apple and Google create “huge blindspot” for 0-day huntersBy Dan Goodin

@freddy @bagder
Single-threaded encoder: *angry noises*
Multi-threaded encoder: *angry noises*

@bagder @freddy

and "uses" in this case means "has it available behind a feature flag in their nightly builds, and does not ship it to normal users because of this very issue"

@freddy @bagder is Firefox using the reference implementation? When I enabled JXL support in Nightly for testing there were some serious rendering artifacts in Firefox that were not present in other implementations (including the PaleMoon browser)

@bagder Are those 100k lines necessary? I mean, I think it could be less than so many...

@bagder We had 100kloc C++ in a smart radiator valve that saved a bunch of extra energy.

I think it is just a reflection that extracting efficiency requires complexity.

@bagder It's a good hot take, but what amazes me most is the replies so far immediately jumping to conclusions with biased gut reactions as if their identity is tied to one or the other camp.

@djh @bagder as much as I like Rust and think that having a Rust implementation is a good thing, I really hope that it doesn't require 100k lines of code.

Side note: I think 100k includes the decoder AND encoder while most clients (incl Firefox) only need the former, which is likely the easier half.

@djh @bagder I also think that it DOES say something about "the internet": the pile of standards and technologies that web browser have to support these days is just wild and one of the reasons why there're only around 3 engines left.

@bagder
And, just wondering:
How many of those lines are for handling security issues such as boobytrapped JPEGs?
How many lines do the other HTML rendering engine use for the same function?
The graphical web has many sins to make amends for!

@dancingtreefrog JPEG-XL, the ASN.1 of the image formats? 😅
@bagder

@bagder
I really don't envy the people who'd have to rewrite that monstrosity.
See flak.tedunangst.com/post/on-bu by @tedu for the current state of the art method of decoding jpegxl safely, which is both hilarious and sad.

flak.tedunangst.comon building jpeg-xl for wasm

@bagder Wait, so JPEG XL isn't completely dead? That's probably not what you meant to communicate but I'm so happy to hear that

fwiw I think that LOC of the reference implementation doesn't really say anything about anything - even if Firefox "adopted" it, which feels like a sensible choice given the state of things

@bagder could isolate the decoder in a WASM runtime and only start the rewrite if and when the format becomes popular enough :-)

@bagder IT complexity is ever increasing snd our dependence on it too…

@bagder Bad things about Google's new format they hope to become widely adopted

@bagder it's all fucked. That's what it says.

@bagder browser vendors should coordinate which subset of JPEG XL they want to support, and only this part of the standard needs to get implemented.

I remember JPEG and that you could never use progressive JPEGs. Some programs even offered an “export for web” feature so that you wouldn't use any unsupported JPEG features.

@bagder To put in perspective:
- JPEG: libjpeg 6b encoder+decoder: 24,200 lines of C
- JPEG: libjpeg-turbo encoder+decoder: 127,000 of C and ASM (multi architectures)
- JPEG2000: openjpeg encoder+decoder: 50,000 lines of .C
- JPEG2000: Kakadu commercial encoder+decoder: 214,000 lines of C++ (only coresys component)
- libjxl: 150,000 lines for the core library, encoder+decoder (deps excluded)
(All above includes blank lines + inline doc)
So this is pretty much standard for a modern codec

@EvenRouault @bagder also looking at the jxl code, the 105k lines in lib/jxl also includes the encoder, test code, and cms code (likely duplicated in the browser). Eliminating just the first two, this comes down to 45k. (if you include code outside lib/jxl you're also getting _an entire reimplementation of libjpeg_ as well as example code)

@EvenRouault @bagder a decade ago I was tasked with implementing jpeg decoding in CUDA on GPUs. After a week of careful study of the problem space, I came back to management with a "lol, this is way harder than we expected"

@bagder I wonder if it's turing complete... something something Pegasus 0-click iMessage exploit.