Skia is a great library, but as all things Google it's a pain to build. They don't use CMake and building it from source takes 20-30 minutes on a modern laptop. Furthermore, it's constantly changing its APIs and much of it is undocumented and unclear on how to use optimally. Most of the decisions taken by development team aren't discussed in the open and this makes it hard to understand the codebase.
I wish there was a nice and small vector graphics library with GPU acceleration. So far Skia is the only real option, despite its downsides.
I have an open source project that uses Skia, and I just keep static libraries for all target platforms because the Skia build process is so painful.
Maybe once a year I bite the bullet, do a new Skia build on all the platforms, and then I have to figure out how the C++ API has changed. At least that’s just rote work of fixing compiler errors by looking at the new header files.
Even though it’s a pain in the ass, I still use Skia because it’s got the best combination of performance and features. Sadly Cairo doesn’t quite compete. Skia gives my project a pretty good guarantee that 2D graphics render like in Chrome, and that’s important for this use case.
Yes. So in Sciter I've replaced its build system with relatively simple premake5 script. That replacement took couple of days but was worth it. Premake5 generates human-readable IDE solutions and make files. So you need just a compiler to build the whole thing.
> building it from source takes 20-30 minutes on a modern laptop.
It is not that bad actually. Just tried full rebuild of x64/Windows version:
Whole sciter.dll (HTML/CSS/JS/Graphics) with Skia backend:
sciter.dll build completed at 9:11 AM and took 07:03.415 minutes
Same sciter.dll but with Direct2D backend:
sciter.dll build completed at 9:22 AM and took 02:34.412 minutes
So Skia takes ~4 minutes to build on pretty average development desktop machine.
> it's constantly changing its APIs
That's very true and is a pain indeed if to change its version frequently. Yet there is no such concept as "Skia version" - just revisions/milestones. It used to be an attempt to make stable plain C API but AFAIR it was removed recently.
We wrote exactly that for our game-focused port of WebKit [1].
CPU renderer uses a tiny, custom fork of Skia (we only use the path rasterizer and their SSE2, AVX2, NEON backends) and our GPU renderer draws directly on GPU via tessellated paths / hardware MSAA (DX11, DX12, GL, Metal, Vulkan).
Our joke was "the recommended way to build Skia is to become a Google employee, but there are workarounds available if for some reason that isn't practical".
There's also the question of "which parts of Skia". If there are five different conceivable ways to implement something in vector graphics, Skia will implement all five, and there will be some sort of hidden obscure configuration setting that Chrome and Android will use to determine which one actually gets used. It's a very unfriendly piece of software to use, honestly.
Out of interest what's difficult about it to build? In my experience CMake isn't exactly a great developer experience, and many projects of this size take similar times to build. Is the problem specific to Skia or Google open source projects, or is it more based on the (necessary) size of the project?
I was skeptical of your claims about building it so I went ahead and downloaded skia and built it myself. It was simple and on my 4 year old desktop (8 cores) it took under a minute to compile skia after it had downloaded its dependencies. All I did was run 2 commands ./tools/git-sync-deps and bazel build //:skia_public. This was not painful at all.
I'd encourage you to look into bazel. It's really a great build system, albeit super opinionated. Should be relatively easy to build Skia as part of your project if you are using Bazel yourself.
I recommend blend2d: https://blend2d.com/. Very well done, very fast. No GPU acceleration but it has a JIT and you can probably get further than you think without it.
Couple things I've seen in this space looking around the past couple weeks...
Flutter made a different engine called Impeller[0] which is replacing Skia. Which is a bit surprising as an ignorant outsider. I hope that works out.
Rive (https://rive.app), is a new animation tool that targets multiple platforms including web and their CEO Guido Rosso gave a great interview on School of Motion[1] about how they are building an animation first vector engine. There is a side by side demo at 46:56[2] of Skia, Impeller and Rive.
Upcoming there's also Vello[0][1] by Raph Levien, who has a bunch of experience w/ font rendering at Google. He's also working on a Rust UI library[2] and has a great talk on compute shaders[3].
I've been following Rive for a while, it's an interesting approach. I think it was a response to the fact that Lottie was tied to AdobeXD (I think?). I'm not sure if Rive's renderer is open source though.
I was curious how Igalia was funded and this was a surprisingly good interview on how they’re structured, how they work with the major browser companies, etc… Apparently many Apple, Google, Firefox engineers left to work for them.
Since they are apparently "powerful" enough to decide major direction of WebKit development as evidenced by OP's article, what exactly is their relationship with Apple in this regard? Like who has the final say and who do the day-to-day decisions?
I'm always curious about the politics and power structure/dynamics of these major open source projects, especially the ones backed up by large companies.
Uhm, I am a bit sad that bringing Cairo up to speed isn't easier, as Cairo is an easier to use dependency than Skia.
I always find building these complex stuff from Google a huge pain - and now they have the additional idea of living on the head and not providing actual releases too...
"Impeller is a new Flutter rendering engine that the Flutter team claims solves the early-onset jank problem. It is designed as a replacement for Skia, with the goal of enabling better animations and addressing the jank issue, while also potentially providing support for 3D, which was not previously possible with Skia, as it exclusively supports 2D. Unlike Skia, Impeller compiles shaders during the build process instead of at runtime.
In Flutter 3.10, Impeller replaces Skia engine and becomes the primary rendering engine on iOS."
I wondered about the license because they had already problems with LibWebTRC which uses BoringSSL (BSD-License). Skia seems to use the new BSD-License without the advertising clause and is therefore compatible with the GPL.
PS: As valleyer mentions - this affects WebKitGtk not all WebKit ports? At least Skia is usable on MacOS/iOS.
I think they try to unify their rendering workflow, just like chromium did when they forked off blink and switched to skia.
In WebKit, however, that implies that they refactor the Bridge API that is used in between contexts and processes which was an internal API before and broke away often.
So I'd guess they start to do incremental changes on the Web API implementations first before they break too much anywhere else (e.g. sidebars, UIs, widgets, devtools are rendered differently but rely on the very same Bridge API)
Could someone who knows Skia internals describe, if possible, the tradeoffs that Skia has made between performance, rendering quality and API DX?
Presumably this is partly why it has become so popular, but as someone who's been writing mostly 2D GL/WebGPU apps for a decade I've only briefly considered a Skia as an alternative, but this is mostly out of ignorance.
I thought always that Safari was the fastest to render web pages on Mac/iOS. But sounds like I was wrong?
> In December 2023 we made the decision of giving Skia a try internally and see if it would be worth the effort of maintaining the project as a third party module inside WebKit. In just one month we had implemented enough features to be able to run all MotionMark tests. The results in the desktop were quite impressive, getting double the score of MotionMark global result. We still had to do more tests in embedded devices which are the actual target of WPE, but it was clear that, at least in the desktop, with this very initial implementation that was not even optimized (we kept our current architecture that is optimized for CPU rendering) we got much better results.
I don't know the full story behind it, but from an outsider's point of view, any open library that pulls that kind of weight for so long should be considered a major feat of engineering.
Somewhat connected question, what is WPE? It’s something that got abstracted out of WebkitGTK, right? Is it a standalone port itself, or is it more like the framework to build a highly specialized one? I’ve seen at least in past versions that libwpe is an optional dependency of WebkitGTK, so they didn’t like abstract and then rebase it on the new component. Or is libwpe separate from WPE?
It's been a few years since I was looking into it, so this might be out of date. But WPE is targeted at kiosks and places you might want to display web content but not have a full web browser. Igalia can sell consulting services to these companies, as opposed to webkitgtk which has a small number of non-paying users. So WPE serves as a place for more active development of webkit-on-linux while not breaking webkitgtk which powers the web browser "Web" on gnome. Things from WPE tend to slowly make it into the webkitgtk build eventually. It's all maintained by the same people.
Looking at https://webkit.org/wpe/, the first design goal is the one that justifies WPE vs other webkit ports: "To provide a no-frills, straight to the point, web runtime for embedded devices."
The other goals, like standards compliant and hardware acceleration, are there to differentiate WPE from non-webkit and ancient-webkit browser engines that people might use on embedded devices.
You could describe WPE as WebKitGTK but you bring your own GTK.
GTK is sometimes inappropriate for embedded devices that have a unique display stack. Using WPE brings in minimal dependencies and can render to anything you desire.
libwpe is just used for some basic code sharing between the two, GTK is not based on WPE.
I wish WebKit GTK was more performant in general (and also in the MDN compatibility list but its another topic). It is getting better but it really is a blocker on shipping quality application with Tauri on Linux. There is a reason most apps using native webviews only target macos and windows, WebKit GfK is mostly undocumented for frontend engineers and often very much outdated / not installed on end user machines.
Please have a look at this one: https://github.com/thorvg/thorvg.
ThorVG is portable and super lightweight, and it's currently undergoing development with WebGPU.
[+] [-] coffeeaddict1|2 years ago|reply
I wish there was a nice and small vector graphics library with GPU acceleration. So far Skia is the only real option, despite its downsides.
[+] [-] pavlov|2 years ago|reply
Maybe once a year I bite the bullet, do a new Skia build on all the platforms, and then I have to figure out how the C++ API has changed. At least that’s just rote work of fixing compiler errors by looking at the new header files.
Even though it’s a pain in the ass, I still use Skia because it’s got the best combination of performance and features. Sadly Cairo doesn’t quite compete. Skia gives my project a pretty good guarantee that 2D graphics render like in Chrome, and that’s important for this use case.
[+] [-] c-smile|2 years ago|reply
Yes. So in Sciter I've replaced its build system with relatively simple premake5 script. That replacement took couple of days but was worth it. Premake5 generates human-readable IDE solutions and make files. So you need just a compiler to build the whole thing.
> building it from source takes 20-30 minutes on a modern laptop.
It is not that bad actually. Just tried full rebuild of x64/Windows version:
Whole sciter.dll (HTML/CSS/JS/Graphics) with Skia backend:
Same sciter.dll but with Direct2D backend: So Skia takes ~4 minutes to build on pretty average development desktop machine.> it's constantly changing its APIs
That's very true and is a pain indeed if to change its version frequently. Yet there is no such concept as "Skia version" - just revisions/milestones. It used to be an attempt to make stable plain C API but AFAIR it was removed recently.
Same thing about Google ANGLE that I started to use recently in Sciter.GLX: https://sciter.com/sciter-glx-beta2/
[+] [-] dkjaudyeqooe|2 years ago|reply
I'm personally skeptical about GPU acceleration being the answer to 2D rendering for various reasons.
I'm looking forward to Blend2D < https://blend2d.com/ > which is JIT based maturing and being the preferred solution.
[+] [-] DrScientist|2 years ago|reply
https://medium.com/@gauravswarankar/flutter-will-use-an-impe...
[+] [-] adamjs|2 years ago|reply
CPU renderer uses a tiny, custom fork of Skia (we only use the path rasterizer and their SSE2, AVX2, NEON backends) and our GPU renderer draws directly on GPU via tessellated paths / hardware MSAA (DX11, DX12, GL, Metal, Vulkan).
[1] https://ultralig.ht
[+] [-] pcwalton|2 years ago|reply
There's also the question of "which parts of Skia". If there are five different conceivable ways to implement something in vector graphics, Skia will implement all five, and there will be some sort of hidden obscure configuration setting that Chrome and Android will use to determine which one actually gets used. It's a very unfriendly piece of software to use, honestly.
[+] [-] danpalmer|2 years ago|reply
[+] [-] charcircuit|2 years ago|reply
[+] [-] jupp0r|2 years ago|reply
[+] [-] zozbot234|2 years ago|reply
https://github.com/linebender/vello is written in Rust and already used as the backend for Xilem, a reactive framework for native UI.
[+] [-] grandinj|2 years ago|reply
We use it in LibreOffice, but its a right pain to update versions and debugging it is.... challenging.
The upside is that the Google Skia team is super friendly and willing to help.
[+] [-] irq-1|2 years ago|reply
Check out nanovg: https://github.com/memononen/nanovg
[+] [-] gct|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] niutech|2 years ago|reply
- NanoVG
- bgfx with vg-renderer
- Impeller
- Starling
[+] [-] leetrout|2 years ago|reply
Flutter made a different engine called Impeller[0] which is replacing Skia. Which is a bit surprising as an ignorant outsider. I hope that works out.
Rive (https://rive.app), is a new animation tool that targets multiple platforms including web and their CEO Guido Rosso gave a great interview on School of Motion[1] about how they are building an animation first vector engine. There is a side by side demo at 46:56[2] of Skia, Impeller and Rive.
0: https://docs.flutter.dev/perf/impeller
1: https://www.youtube.com/watch?v=U0Jd5-eStu4&t=2514s
2: https://youtu.be/U0Jd5-eStu4?si=8vv3c2bw3VumLzeu&t=2816
[+] [-] darzu|2 years ago|reply
0: https://www.youtube.com/watch?v=mmW_RbTyj8c
1: https://github.com/linebender/vello
2: https://www.youtube.com/watch?v=zVUTZlNCb8U
3: https://www.youtube.com/watch?v=DZRn_jNZjbw
[+] [-] danielvaughn|2 years ago|reply
[+] [-] tadfisher|2 years ago|reply
0: https://docs.gtk.org/gsk4/
[+] [-] vthommeret|2 years ago|reply
https://thenewstack.io/igalia-the-open-source-powerhouse-you...
[+] [-] thrdbndndn|2 years ago|reply
Since they are apparently "powerful" enough to decide major direction of WebKit development as evidenced by OP's article, what exactly is their relationship with Apple in this regard? Like who has the final say and who do the day-to-day decisions?
I'm always curious about the politics and power structure/dynamics of these major open source projects, especially the ones backed up by large companies.
[+] [-] spaniard89277|2 years ago|reply
[+] [-] infogulch|2 years ago|reply
https://news.ycombinator.com/item?id=37430579
[+] [-] leonheld|2 years ago|reply
[+] [-] a1o|2 years ago|reply
I always find building these complex stuff from Google a huge pain - and now they have the additional idea of living on the head and not providing actual releases too...
[+] [-] maattdd|2 years ago|reply
"WebKitGTK and WPEWebKit Switching to Skia for 2D Graphics Rendering"
Can we update the title here also?
[+] [-] zerr|2 years ago|reply
[+] [-] canucker2016|2 years ago|reply
"Impeller is a new Flutter rendering engine that the Flutter team claims solves the early-onset jank problem. It is designed as a replacement for Skia, with the goal of enabling better animations and addressing the jank issue, while also potentially providing support for 3D, which was not previously possible with Skia, as it exclusively supports 2D. Unlike Skia, Impeller compiles shaders during the build process instead of at runtime.
In Flutter 3.10, Impeller replaces Skia engine and becomes the primary rendering engine on iOS."
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] tapirl|2 years ago|reply
It is long-time known pain point that the skia official doesn't provide a usable C API.
[+] [-] simscitizen|2 years ago|reply
[+] [-] jessevdk|2 years ago|reply
[+] [-] ho_schi|2 years ago|reply
I wondered about the license because they had already problems with LibWebTRC which uses BoringSSL (BSD-License). Skia seems to use the new BSD-License without the advertising clause and is therefore compatible with the GPL.
PS: As valleyer mentions - this affects WebKitGtk not all WebKit ports? At least Skia is usable on MacOS/iOS.
[+] [-] sph|2 years ago|reply
[+] [-] thrwwycbr|2 years ago|reply
In WebKit, however, that implies that they refactor the Bridge API that is used in between contexts and processes which was an internal API before and broke away often.
So I'd guess they start to do incremental changes on the Web API implementations first before they break too much anywhere else (e.g. sidebars, UIs, widgets, devtools are rendered differently but rely on the very same Bridge API)
[+] [-] krona|2 years ago|reply
Presumably this is partly why it has become so popular, but as someone who's been writing mostly 2D GL/WebGPU apps for a decade I've only briefly considered a Skia as an alternative, but this is mostly out of ignorance.
[+] [-] mrpippy|2 years ago|reply
[+] [-] spixy|2 years ago|reply
[+] [-] miohtama|2 years ago|reply
> In December 2023 we made the decision of giving Skia a try internally and see if it would be worth the effort of maintaining the project as a third party module inside WebKit. In just one month we had implemented enough features to be able to run all MotionMark tests. The results in the desktop were quite impressive, getting double the score of MotionMark global result. We still had to do more tests in embedded devices which are the actual target of WPE, but it was clear that, at least in the desktop, with this very initial implementation that was not even optimized (we kept our current architecture that is optimized for CPU rendering) we got much better results.
[+] [-] valleyer|2 years ago|reply
... for the GTK and WPE ports. Not on Apple platforms.
[+] [-] rezmason|2 years ago|reply
https://en.wikipedia.org/wiki/Cairo_(graphics)#Notable_usage
I don't know the full story behind it, but from an outsider's point of view, any open library that pulls that kind of weight for so long should be considered a major feat of engineering.
[+] [-] prosody|2 years ago|reply
[+] [-] JoelEinbinder|2 years ago|reply
Looking at https://webkit.org/wpe/, the first design goal is the one that justifies WPE vs other webkit ports: "To provide a no-frills, straight to the point, web runtime for embedded devices."
The other goals, like standards compliant and hardware acceleration, are there to differentiate WPE from non-webkit and ancient-webkit browser engines that people might use on embedded devices.
[+] [-] TingPing|2 years ago|reply
GTK is sometimes inappropriate for embedded devices that have a unique display stack. Using WPE brings in minimal dependencies and can render to anything you desire.
libwpe is just used for some basic code sharing between the two, GTK is not based on WPE.
[+] [-] musicale|2 years ago|reply
[1] https://en.wikipedia.org/wiki/QuickDraw_GX
[2] https://en.wikipedia.org/wiki/Skia_Graphics_Engine
[+] [-] Sytten|2 years ago|reply
[+] [-] hermet|2 years ago|reply
[+] [-] Jarred|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]