In Chrome, Skia is used to render paint commands from Blink and the browser UI into pixels on your screen, a process called rasterization. Skia has powered Chrome Graphics since the very beginning. Skia eventually ran into performance issues as the web evolved and became more complex, which led Chrome and Skia to invest in a GPU accelerated rasterization backend called Ganesh.
Over the years, Ganesh matured into a solid highly performant rasterization backend and GPU rasterization launched on all platforms in Chrome on top of GL (via ANGLE on Windows D3D9/11). However, Ganesh always had a GL-centric design with too many specialized code paths and the team was hitting a wall when trying to implement optimizations that took advantage of modern graphics APIs in a principled manner.
This set the stage for the team to rethink GPU rasterization from the ground up in the form of a new rasterization backend, Graphite. Graphite was developed from the start to be principled by having fewer and more comprehensible code paths. This forward looking design helps take advantage of modern graphics APIs like Metal, Vulkan and D3D12 and paradigms like compute based path rasterization, and is multithreaded by default.
↫ Michael Ludwig and Sunny Sachanandani at the Chromium Blog
The level of complexity in browsers and their rendering engines blows my mind every time I read about it. When I first got access to the internet, it consisted of static pages with text and still images, but now browser engines are almost as complex as entire operating systems. Not all of that progress has been good – boy has a lot of it not been good – but we’re stuck with it now, and thus people making browsers have to deal with stuff like this.
If you ever wonder why there really only are two browser engines in the world – Google’s Blink and Apple’s WebKit – this is your answer. Who in their right mind wants to develop something like this from scratch and compete with Google and Apple?
I wouldn’t say Mozilla’s Gecko is quite dead yet. It’s certainly good enough for me to daily drive without running into any sites that don’t work with it.
ssokolow (Hey, OSNews, U2F/WebAuthn is broken on Firefox!),
Here here!
FF working well for me as a daily driver Incompatible websites are rare and IMHO FF is fairly well polished. I am concerned about the future, but it seems very premature to speak as though FF didn’t exist at all.
I came here to say the same thing. It must just be an oversight that Thom skipped Firefox as it is such a frequent and charged topic for him. Either that or it is a statement that he does not consider it an option anymore.
While Blink, Webkit, and Gecko all obviously have to be listed no matter your criteria, I think the list is really quite a bit longer these days.
You can use OSnews and quite a lot of the rest of the web on Ladybird already. It is close enough that ignoring it completely seems like misinformation. I expect it will be fully on par with the big three in about a year or so (not long).
The Flow browser (the proprietary one) is pretty close too. As there is another Flow, that uses Chromium I will link to the one I mean.
https://www.ekioh.com/flow-browser/
Servo is certainly a viable browser engine for specialized tasks (like kiosks). It is coming along pretty quickly now even if we are not all going to be using Servo based web browsers on our desktops this year.
And then there is a long tail of browser engines that are certainly not in the category of the big three, or even Ladybird. I would not expect them to make Thom’s list of course but they are there.
Written using Firefox on Android.
It’s super weird to leave out Firefox/Gecko (written in Firefox…)
“Who in their right mind wants to develop something like this from scratch and compete with Google and Apple?”
Andreas Kling (author of SerenityOS) and a group of developers are trying to do exactly that:
https://ladybird.org
Except Ladybird uses Skia. They stopped using their own LibGfx library.
So, I guess they do not want “to develop something like this from scratch and compete with Google” either.
“This” in Thom’s sentence refers to Skia.
No criticism. I love Ladybird.
Bummer 🙁
Somehow this move seems strange …
Was LibGfx really that bad? Why not improve it?
When Ladybird split from SerenityOS, they also gave up on their “everything from scratch” philosophy. The initial announcement of the split said this: “Unlike SerenityOS, Ladybird will have a relaxed NIH policy (instead of ‘no 3rd party code!’), and will leverage the greater OSS ecosystem”.
One of the first things Ladybird did was adopt third-party Open Source libraries for things like font handling, image formats, video codecs, and cryptography. Adopting Skia as the graphics library came not long after.
I am still not sure how I feel about it.
On the one hand, it is very pragmatic which I like. There is absolutely no doubt it will greatly accelerate how quickly we get a truly usable Ladybird browser which of course I love. And all it really means is the the Ladybird team is concentrating on code that is truly web browser code and not just support libraries that could be used for any application. Do we really want the Ladybird team writing the cryptography libraries and AV1 codecs?
On the other hand, I REALLY liked the idea of Ladybird being truly independent. And I also really liked the idea of SerenityOS creating everything needed for the core OS inside a single monolithic code repository. Andreas talked about the freedom of having access to the entire stack and being able to change anything at any level without dependencies on other projects. I loved that.
What I am perhaps most sad about is that Ladybird dropped support for SerenityOS when they split. But I think that decision is simply a consequence of the decision to adopt third-party code. You cannot build Ladybird as part of SerenityOS precisely because SerenityOS is trying to build LibGfx instead of using Skia.
The good news is that Ladybird will get all the amazing performance benefits talked about in Thom’s article basically for free as part of Skia. That is pretty cool. Making LibGfx as fast as Skia would take time. Time that is probably better spent passing Web Platform Tests or speeding up Javascript. And LibGfx lacked quite a few features required for the current level of CSS support in Ladybird too.
Even if LibGfx continues to improve, it seems unlikely that Ladybird will ever go back. But I guess my concerns about Chrome are not that Google will monopolize the graphics renderer space. I am more worried about things like Manifest V3, tracking, privacy, user monetization, adherence to web standards, and an escape from browser mono-culture. Ladybird still gives us all that.
I just noticed this from the Ladybird FAQ:
“We are already using some of the same 3rd party libraries that other browsers use, but we will never adopt another browser engine instead of building our own.”
I guess that is what matters.
cybergorf,
It’s something I’d personally be willing to do if I could be paid…If they had plenty of money to throw around, then why not, but honestly it probably wouldn’t be the best use of money. I agree with LeFantome – it’d be nice to have, but given limited resources and more pressing engineering challenges to overcome, this isn’t a priority.
@cybergorf
If you are a Ladybird fan, you may enjoy this.
I am typing this comment from Ladybird, built from Git a few minutes ago. Out of curiousity, I went to the site https://html5test.co where Ladybird scored a 471 out of 588. That is the exact same score as Safari 11.1.
Ladybird is still very slow but it is getting there.
That is great news!
I was initially hoping Ladybird would keep its dependencies down to a minimum, which would have made it more portable to other systems … but nevertheless I am still a fan of this project.
I hear you. The dependencies are all fairly portable as well. All things widely used in other Open Source projects. Anything POSIX should be no problem. The project does not officially support Windows yet but apparently there is a community effort to add that which is making some progress.
Perhaps the biggest obstacle to portability will be Skia actually. The library is quite portable in that they support Linux, macOS, Linux, iOS, and Android. Unfortunately, they regularly deprecate older systems. I mean this makes sense reading this article and all the advanced GPU tricks and Vulkan APIs and things that they want to leverage. However, it does limit portability, especially to older systems. This is what the current Skia release says it supports:
– Windows 10, 11
– macOS 11 or later
– iOS 13 or later
– Android 4.3 (JellyBean) or later
– Ubuntu 18.04+, Debian 10+, openSUSE 15.2+, or Fedora Linux 32+
I can tell you that it supports many more Linux systems than listed but probably only those that are similarly up to date. I think Skia is the reason LibreOffice dropped support for Windows 7 and 8. So, no Ladybird for ReactOS. And not for SerenityOS either. As I understand it, Skia is what blocked a recent effort to port Ladybird to Haiku.
The more I write here, the sadder I get that they removed LibGfx actually. The original Ladybird code, with LibGfx, still exists in SerenityOS but I think they want to remove cross-platform support. One of them should really change the name. The two projects are going to diverge A LOT.
As for Ladybird portability, another spanner in the works is that Andreas wants to move from C++ to Swift as the preferred language for the project. I do not think they are “rewriting” it but they will add more and more Swift over time. So, Swift will become a hard dependency. Will everywhere you want to run Ladybird have a working Swift compiler?
And….a final portability hiccup. The current Ladybird build system uses Microsoft vcpkg to manage all these dependencies (I assume because Mr. Kling uses Clion). And the bundled vcpkg binary they use requires glibc. My system is musl based. I can build a musl vcpkg but my 10 minute attempt failed to make Ladybird build on my musl system. I used to build SerenityOS and Ladybird on a musl system no problem but the move to vcpkg killed that for me. So…I build it in an Arch Distrobox which uses glibc instead. Color me annoyed.
Despite all this, I am still very excited for Ladybird. And I am grateful that they are making such rapid progress. As they mature, I also have no doubt that some of these portability issues (like building on musl) will be addressed. Right now, they are building for themselves so that they can move fast. Fair enough. As above, they are even ignoring Windows for now (at least in the official project).
You are not wrong though that, while we have also gained, we have lost something with this move to third-party libraries in Ladybird. Portability is one. Full control over the project is another. The values of Ladybird are not the values of SerenityOS, which is interesting given that the culture of both is set by the same guy.
LeFantome,
At least the unaccelerated code paths are likely compatible with older versions of windows. Typically microsoft library version checks are responsible for breaking backwards compatibility rather than any actual incompatibilities with the software or API. I see this all the time when updating visual studio. There’s a very good chance that compiling the code using the exact same API would work fine with win7 libraries. Naturally this won’t be officially supported, but for projects that are willing to rebuild Skia themselves, there’s a good chance the windows 10 code also works on windows 7 very minimal changes.
Many projects are based on C/C++, including my own, but its an obstacle to robust software. Swift may be a better choice, but it may cut out significant swaths of the developer base. It’s hard to say whether a more advanced language with a fraction of mind-share is the right call. Popularity and feature-wise C# may have been a better choice. Rust could have been interesting too.
I agree, I wouldn’t favor that dependency for this kind of project.
Yeah, there are pros and cons to “NIH”.. Many of us would be qualified to build/support a purpose built graphics stack, and it would be nice for Ladybird to have this, but it may not be the best use of resources when Skia is already there. Same deal with 3d game engines. We probably have millions of developers who have the skills to build one but is it worthwhile given that using one that already exists saves so much time? There’s a big trade off between independence and time commitment.
Edit: Having said this, the point that it’s not worth reinventing the wheel could be used to dismiss the browser project entirely… We do it because we want choice.
Does anybody know the implications of this for Skia in other contexts? The article says that Skia is the graphics library for Chrome, which is true, but it is quite a popular Open Source library well beyond that.
Skia is used as a graphics library in .NET, Unity, Qt, Inkscape, Krita, LibreOffice, and even Firefox. Of course, Google also uses it in Flutter, ChromeOS, and Android.
Wait. Ladybird uses Skia too!
https://ladybird.org/newsletter/2024-07-31/
So, Ladybird, the “only browser that is not dependent on Google”, relies on a pretty big chunk of code written by Google. I am not sure why I never put that together before. It is not surprising, Skia is the industry standard. Ladybird had their own LibGfx library from SerenityOS but it was not as good. There is also Cairo as used by GTK/GNOME but it is honestly not as good either (certainly slower). I think GTK4 may have an updated renderer that uses the GPU more but I am not sure if it can be used as a stand-alone library. Skia is king of the hill.
In addition to the Google dependency, using Skia has other implications. As per a recent OSnews article, I am pretty sure Skia is the reason that LibreOffice dropped support for older versions of Windows for example. Skia is BSD licensed.