Could just be the “Google is a big company with different teams who don’t necessarily agree with each other” effect.
I remember hearing somewhere that Microsoft suffers from the Windows, Office, and Visual Studio teams having a somewhat adversarial relationship with each other and I think it might have been the story of ispc where I read that Intel’s corporate culture has a somewhat self-sabotaging “make the teams compete for resources and let the fittest ideas win out” element to it.
Microsoft suffers from the Windows, Office, and Visual Studio teams having a somewhat adversarial relationship with each other
It’s less bad than it was. In particular, Visual Studio is no longer regarded as a direct revenue source and is largely driven by ‘Azure Attach’ (good developer tools with Azure integration make people deploy things in Azure). In the ‘90s, I’m told, it was incredibly toxic because they had directly competing incentives.
Windows wanted to ship rich widget sets so that developing on Windows was easy and Windows apps were better than Mac ones and people bought Windows.
The developer division wanted those same widgets to be bundled with VB / VC++ so that developers had to buy them (but could then use them for free in Windows apps), so developing for Windows with MS tools was easy and so people would by MS developer tools.
The Office team wanted to ensure that anything necessary to build anything in the Office suite was a part of MS Office, so creating an Office competitor was hard work. They didn’t want rich widget sets in Windows because then anyone could easily copy the Office look and feel.
This is why there still isn’t a good rich text editing control on Windows. Something like NSTextView (even the version from OPENSTEP) has everything you need to build a simple word processor and makes it fairly easy to build a complex one and the Office team hated that idea.
Another reason Office implemented their own…well, everything…is that they wanted to have the same UX in older versions of Windows, and be able to roll out improvements with nothing but an Office install. In many customer environments Office was upgraded more often than Windows.
For the OG Office folks, I think Windows was regarded as “device drivers for Office”. (Which, to be fair, it basically was in version 1.)
(I used to be on the Windows Shell team, having the same hopeless conversation annually about getting Office to adopt any of our components.)
I guess the browser is in a similar position, but browser vendors seem OK with using (some) native OS components, perhaps because they grew up with a different political relationship with the OSes than Office.
We will be removing the JPEG XL code and flag from Chromium for the following reasons:
Experimental flags and code should not remain indefinitely
There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL
The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default
By removing the flag and the code in M110, it reduces the maintenance burden and allows us to focus on improving existing formats in Chrome
The Google JPEG XL team wants to reverse this decision.
Concerning the “not enough interest from the ecosystem” argument, it’s noted that Safari has since added JPEG XL support (after Chrome dropped it). The team has made progress towards convincing Mozilla to add JPEG XL support, but they need to deliver a Rust implementation. If Mozilla and Safari both have JPEG XL, it means increased ecosystem interest.
Concerning the “maintainance burden” argument, Mozilla is hesitant to add 100,000 lines of concurrent C++ to their codebase, given the cost (increased attack surface of that kind of code), vs the benefit. If the decoder is written in safe Rust, the maintenance burden decreases.
The reference implementation in C++ (libjxl) is developed by people on Google’s payroll. Only one person on the JXL team is outside of Google. They’re at Google Research in Zurich, and don’t follow orders from the Chromium team.
One point because I’ve seen it come up elsewhere: I asked on the JPEG XL Discord to which degree they’ll prioritize correctness and safety in the new implementation, and I was told that they believe they can get away with close to zero unsafe while still achieving really good performance.
I think rust is pretty fit for that kind of things. In that kind of work, unsafe rust is more useful for ensuring the optimisations you want are performed than outsmarting lifetime checks (typically, ensuring iterators abstractions get stripped out). I think that’s also not the same kind of unsafe code to review than with complex data structures that have to do smart pointer manipulations.
I’ve worked on jpeg-like enc/decoders in C/C++ before, and always thought rust would be a great fit for them !
Having two independent implementations is the basic requirement of Web standards.
This proves that the spec is actually possible to implement. It makes uses in the wild much less likely to depend on bugs in a particular implementation, which makes it possible to upgrade or replace implementations without creating compatibility problems.
AVIF went through this already. There were real differences between Safari, Firefox, and Chrome that had to be worked out.
This is a great step towards JXL becoming a real web standard. Alternative implementations have already helped find some cases where the ISO spec and the reference C++ library disagreed.
Having two independent implementations is the basic requirement of Web standards.
There are already multiple independent implementations, this has nothing to do with that. The developer jxl-oxide identified numerous problems such as what you mention while developing that library. I think Mozilla just wants whatever library they depend on to be supported by a paid team that can respond to issues in a timely manner, as opposed to a hobby project developed by one person. Of course, it’s quite possible that whatever the JXL team delivers to Mozilla will be based on jxl-oxide.
The decoder should also be fast. I cannot find data online on the decoding performance of jxl-oxide compared to the C++ implementation. ( https://github.com/libjxl/bench is a “conformance bench”, which indicate that jxl-oxide correctly decodes all images on the conformance tests, but does not measure decoding performance. )
Yeah. I happen to know that jxl-oxide is slower in most, but not all, cases. The question really is whether the JXL team should use jxl-oxide as a starting point for something faster, or make a new library from scratch.
I missed the previous JPEG XL drama, and this is a bit of a low effort comment, but let me just say that “extra large” is probably not the branding I’d want to go with on a new image format. Of course that’s not what it is intended to stand for, but that’s how I (and probably others) read it.
From Wikipedia:
The name consists of JPEG (for the Joint Photographic Experts Group, which is the committee which designed the format), X (part of the name of several JPEG standards since 2000: JPEG XT, JPEG XR, JPEG XS), and L (for long-term). The L was included because the authors’ intention is for the format to replace the legacy JPEG and last just as long, too.
Wikipedia is not correct (probably). As far as I know, the “L” didn’t really mean anything, but might’ve actually meant “large” as a counter to JPEG XS. That it might mean “long-term” was invented later by one of the developers. Notably, the name was chosen before the call for proposals, so that developer wasn’t even a member of the the JPEG committee at the time the name was chosen.
I’m curious why Google is writing it, given that they removed JPEG XL support from Chromium. Are they considering adding it back?
Could just be the “Google is a big company with different teams who don’t necessarily agree with each other” effect.
I remember hearing somewhere that Microsoft suffers from the Windows, Office, and Visual Studio teams having a somewhat adversarial relationship with each other and I think it might have been the story of ispc where I read that Intel’s corporate culture has a somewhat self-sabotaging “make the teams compete for resources and let the fittest ideas win out” element to it.
It’s less bad than it was. In particular, Visual Studio is no longer regarded as a direct revenue source and is largely driven by ‘Azure Attach’ (good developer tools with Azure integration make people deploy things in Azure). In the ‘90s, I’m told, it was incredibly toxic because they had directly competing incentives.
Windows wanted to ship rich widget sets so that developing on Windows was easy and Windows apps were better than Mac ones and people bought Windows.
The developer division wanted those same widgets to be bundled with VB / VC++ so that developers had to buy them (but could then use them for free in Windows apps), so developing for Windows with MS tools was easy and so people would by MS developer tools.
The Office team wanted to ensure that anything necessary to build anything in the Office suite was a part of MS Office, so creating an Office competitor was hard work. They didn’t want rich widget sets in Windows because then anyone could easily copy the Office look and feel.
This is why there still isn’t a good rich text editing control on Windows. Something like NSTextView (even the version from OPENSTEP) has everything you need to build a simple word processor and makes it fairly easy to build a complex one and the Office team hated that idea.
Another reason Office implemented their own…well, everything…is that they wanted to have the same UX in older versions of Windows, and be able to roll out improvements with nothing but an Office install. In many customer environments Office was upgraded more often than Windows.
For the OG Office folks, I think Windows was regarded as “device drivers for Office”. (Which, to be fair, it basically was in version 1.)
(I used to be on the Windows Shell team, having the same hopeless conversation annually about getting Office to adopt any of our components.)
I guess the browser is in a similar position, but browser vendors seem OK with using (some) native OS components, perhaps because they grew up with a different political relationship with the OSes than Office.
Yep, after all Google was a primary contributor to JXL, both from PIK and directly.
Different teams.
There are teams at Google that kept telling Chrome they had need for it and budget to do it. In the public bugtracker.
Chrome still yanked it. Seems the teams with the need and budget still have both.
The reasons Chrome gave for removing JPEG XL support were:
The Google JPEG XL team wants to reverse this decision.
The reference implementation in C++ (libjxl) is developed by people on Google’s payroll. Only one person on the JXL team is outside of Google. They’re at Google Research in Zurich, and don’t follow orders from the Chromium team.
One point because I’ve seen it come up elsewhere: I asked on the JPEG XL Discord to which degree they’ll prioritize correctness and safety in the new implementation, and I was told that they believe they can get away with close to zero unsafe while still achieving really good performance.
I think rust is pretty fit for that kind of things. In that kind of work, unsafe rust is more useful for ensuring the optimisations you want are performed than outsmarting lifetime checks (typically, ensuring iterators abstractions get stripped out). I think that’s also not the same kind of unsafe code to review than with complex data structures that have to do smart pointer manipulations. I’ve worked on jpeg-like enc/decoders in C/C++ before, and always thought rust would be a great fit for them !
Having two independent implementations is the basic requirement of Web standards.
This proves that the spec is actually possible to implement. It makes uses in the wild much less likely to depend on bugs in a particular implementation, which makes it possible to upgrade or replace implementations without creating compatibility problems.
AVIF went through this already. There were real differences between Safari, Firefox, and Chrome that had to be worked out.
This is a great step towards JXL becoming a real web standard. Alternative implementations have already helped find some cases where the ISO spec and the reference C++ library disagreed.
There are already multiple independent implementations, this has nothing to do with that. The developer jxl-oxide identified numerous problems such as what you mention while developing that library. I think Mozilla just wants whatever library they depend on to be supported by a paid team that can respond to issues in a timely manner, as opposed to a hobby project developed by one person. Of course, it’s quite possible that whatever the JXL team delivers to Mozilla will be based on jxl-oxide.
The decoder should also be fast. I cannot find data online on the decoding performance of jxl-oxide compared to the C++ implementation. ( https://github.com/libjxl/bench is a “conformance bench”, which indicate that jxl-oxide correctly decodes all images on the conformance tests, but does not measure decoding performance. )
Yeah. I happen to know that jxl-oxide is slower in most, but not all, cases. The question really is whether the JXL team should use jxl-oxide as a starting point for something faster, or make a new library from scratch.
I missed the previous JPEG XL drama, and this is a bit of a low effort comment, but let me just say that “extra large” is probably not the branding I’d want to go with on a new image format. Of course that’s not what it is intended to stand for, but that’s how I (and probably others) read it.
From Wikipedia:
Wikipedia is not correct (probably). As far as I know, the “L” didn’t really mean anything, but might’ve actually meant “large” as a counter to JPEG XS. That it might mean “long-term” was invented later by one of the developers. Notably, the name was chosen before the call for proposals, so that developer wasn’t even a member of the the JPEG committee at the time the name was chosen.