Why do browsers need to support every media format? Why can't it be shipped as a shared library for the whole system to use?

▲ groundzeros2015 3 minutes ago | parent | next [-]

Because browsers want to provide a consistent platform and can’t rely on OS vendors to do it in the way they need and prioritize their interests.

▲ EvanAnderson 2 hours ago | parent | prev | next [-]

> Why can't it be shipped as a shared library for the whole system to use?

Flashbacks to DataTypes on the Amiga: https://wiki.amigaos.net/wiki/Datatypes_Library

	▲	Findecanor an hour ago \| parent [-]
		My favourite tidbit about the Amiga is that it was the first platform that got PNG support in all its web browsers: you just had to install the png.datatype.

▲ burnte an hour ago | parent | prev | next [-]

This way browser vendors control what their app supports, and won't have something break because a user doesn't have a library.

▲ alwillis 3 hours ago | parent | prev | next [-]

> Why can't it be shipped as a shared library for the whole system to use?

That's how it works on macOS; the bundled apps (Preview, Photos, etc.) gained support for JPEG XL.

▲ lxgr 3 hours ago | parent | prev | next [-]

Given that there are more operating systems than browser engines these days, I'm not sure this would be an unequivocal win.

▲

arghwhat an hour ago | parent [-]

Eh. WebKit, Blink, Gecko being the big ones, supporting Windows, Linux (and alikes — maybe one would consider Android separate in this context) and Darwin (in this context iOS/macOS is the same). Mostly 1:1.

The thing is that it's still just a library, it just happened to be pre-installed. CGImage is just a helper in the Core Graphics library, not some magical "native"/"core" functionality in the OS that would be different than any other library with the same features.

An equivalent library for Linux (glycin for example), or per-format libraries like jxl-rs, are not "included in the OS", and tend to be the very same libraries one would use for Windows. If that does the trick on most platforms, then why have the maintenance burden of doing something different on macOS if all it does is save a few bytes on disk?

From Google's perspective, they would likely not want Chrome for macOS to gain support for jxl as the sole platform anyway, even if they are using CGImage and could decode it that way...

	▲	lxgr 32 minutes ago \| parent [-]
		I'd definitely consider Android separate from Linux, yes. Their multimedia subsystems are completely different. The same applies to tons of embedded Linux platforms running an embedded Chromium or WebKit. Browsers have also largely switched to handling most aspects of TLS and certificates themselves, despite there being OS libraries for those as well; the same applies to HTTP.

▲ code_duck 3 hours ago | parent | prev | next [-]

Google seems to prefer reimplementing every portion of an OS possible in Chrome.

▲ DC-3 3 hours ago | parent [-]

If you want things to work every single time on a billion different devices this is how you do it.

▲ titzer 2 hours ago | parent [-]

Yeah, and then 100 different apps can repackage the browser engine as an Electron app, each weigh 300+mb.

I saw this recently with Balena etcher. It's a firmware flashing app with about 10 buttons total. It's over 400mb because it's written in node and has an electron GUI.

Good jerb.

▲ encom an hour ago | parent [-]

When your flashing app starts getting bigger than the operating systems it's writing, you should start asking yourself some questions.

  ~$ du -h $(which dd)
  76K     /usr/bin/dd

Etcher truly is the clowniest Electron app of them all.

	▲	mort96 33 minutes ago \| parent \| next [-]
		Better and similar size: `$ du -h $(which pv) 116K /usr/bin/pv` pv has a progress bar and nicer syntax. Next time you need to write an image, try: `sudo pv -Yo /dev/blah /path/to/your/image.img` The -Y makes it sync after each write so that the progress bar represents actual progress instead of just how fast you can copy to kernel write buffers. My life improved measurably after I contributed that '-o' flag to pv and it then made its way into all my systems through regular OS updates :)
	▲	titzer 32 minutes ago \| parent \| prev [-]
		Long live dd! Except every time I use it I am terrified I'll blow out the brains of the wrong device :/ Another example clown app: the MacOS downloads of TuxGuitar, a Java app, used to just ship as a zip with a big jar in it. Now it ships an entire Java Runtime environment specific to your processor architecture. It's 480MB. Derp.

▲ looperhacks 3 hours ago | parent | prev | next [-]

But it is a shared library? It's used in both Chrome and Firefox.

	▲	spider-mario 3 hours ago \| parent [-]
		Which both vendor it.

▲ echelon 3 hours ago | parent | prev [-]

Such an important piece of software does not want to subject itself to the packaging and support woes of shared libraries. There are security issues, maintainability issues, and much more headache by going with that approach.

Static linking is one and done, headache gone. People have large drives these days, so it's not a problem.

There are areas where the browser will dynamically link, but those are more OS-related than image and file format codecs.