Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebKit switching to Skia for 2d graphics rendering

blogs.igalia.com

Post reply on HN
Print view View original

101–110 of 181 posts

Re: WebKit switching to Skia for 2d graphics rendering

#101

Post by c-smile »

coffeeaddict1 wrote: post #37

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…

> it's a pain to build

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.

Same thing about Google ANGLE that I started to use recently in Sciter.GLX: https://sciter.com/sciter-glx-beta2/

Re: WebKit switching to Skia for 2d graphics rendering

#102

Post by nox101 »

zozbot234 wrote: post #91
coffeeaddict1 wrote: post #37

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…

> I wish there was a nice and small vector graphics library with GPU acceleration. https://github.com/linebender/vello is written in Rust and already used as the backend for Xilem, a reactive framework for native UI.

Vello is used in Skia

https://skia.googlesource.com/skia/+/2e551697dc56/third_part...

Re: WebKit switching to Skia for 2d graphics rendering

#103

Post by TingPing »

thrdbndndn wrote: post #48
vthommeret wrote: post #23

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. https://thenewstack.io/igalia-the-open-source-powerhouse-you...

Thanks for the article, I never heard of 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 b…

To be clear WebKit is made up of multiple ports. These ports are maintained by their own groups and Igalia maintains WebKitGTK/WPE where this change is happening. It does not affect the Apple ports of WebKit.

To answer your question though. WebKit is Apple's project and they do the majority of contributions. Igalia is the second largest contributor and collaborates with Apple regularly. Within the GTK/WPE ports Igalia controls them.

Re: WebKit switching to Skia for 2d graphics rendering

#104

Post by TingPing »

Sytten wrote: post #88

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.

The performance improvements of WebKitGTK aren't small, in my personal benchmarks on like MotionMark, performance has doubled in recent years and that is before Skia.

Re: WebKit switching to Skia for 2d graphics rendering

#105

Post by Wowfunhappy »

Sytten wrote: post #88

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.

> I wish WebKit was [...] in the MDN compatibility list

Are the capabilities substantially different from Apple webkit?

Re: WebKit switching to Skia for 2d graphics rendering

#106

Post by gcr »

pavlov wrote: post #61
coffeeaddict1 wrote: post #37

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…

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 s…

Out of curiosity, why do you rebuild? What kinds of new features would get you to want to upgrade?

Re: WebKit switching to Skia for 2d graphics rendering

#107

Post by tetromino_ »

gigatexal wrote: post #90
gigatexal wrote: post #54

Earlier quoted context omitted.

What happened to Cairo the 2d graphics tool?

Can it be GPU accelerated? (Is that even a dumb question to ask?)

Cairo has only limited support for GPU acceleration and hasn't seen much development this decade. So users who care about performance have either switched away from Cairo entirely or are at least reducing its usage and are taking it out of the fast path.

Re: WebKit switching to Skia for 2d graphics rendering

#108

Post by TingPing »

Wowfunhappy wrote: post #105
Sytten wrote: post #88

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.

> I wish WebKit was [...] in the MDN compatibility list Are the capabilities substantially different from Apple webkit?

The majority of web features are the same, though some do require some platform specific work.

There are a few big differences like WebRTC support isn't in WebKitGTK releases.

Re: WebKit switching to Skia for 2d graphics rendering

#109

Post by adamjs »

coffeeaddict1 wrote: post #37

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…

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).

[1] https://ultralig.ht

Re: WebKit switching to Skia for 2d graphics rendering

#110

Post by Asm2D »

fxtentacle wrote: post #72
dkjaudyeqooe wrote: post #52

Earlier quoted context omitted.

> I wish there was a nice and small vector graphics library with GPU acceleration. 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.

According to their benchmark, multi-threaded rendering on a Ryzen 7950X will take about 1.7ms with 4 cores for drawing 1000x polygons with 40 vertices each on a 32x32 px area, which seems like a reasonable approximation for a text character on a high-DPI display. The default font size in JetBrains fits about 2500 characters onto my screen, so I'd expect a 4.25ms frame time, meaning I am capped at 235 FPS with 4 CPU c…

Text rendering is something that will get improved in the future.

At the moment when you render text Blend2D queries each character from the font and then rasterizes all the edges and runs a pipeline to composite them. All these steps are super optimized (there is even a SIMD accelerated TrueType decoder, which I have successfully ported to AArch64 recently), so when you compare this approach against other libraries you still get like 4-5x performance difference in favor of Blend2D, but if you compare this method against cached glyphs Blend2D loses as it has to do much more work per glyph.

So the plan is to use the existing pipeline for glyphs that are larger (let's say 30px+ vertically) and to use caching for glyphs that are smaller, but how it's gonna be cached is currently in research as I don't consider simple glyph caching in a mask a great solution (it cannot be sub-pixel positioned and it cannot be rotated - and if you want that subpixel positioned the cache would have to store each glyph several times).

There is a demo application in blend2d-apps repository that can be used to compare Blend2D text rendering vs Qt, and the caching Qt does is clearly visible in this demo - when the text is smaller Qt renders it differently and characters can "jump" from one pixel to another when the font size is slightly scaled up and down, so Qt glyph caching has its limits and it's not nice when you render animated text, for example. This is a property that I consider very important so that's why I want to design something better than glyph masks that would be simple to calculate on CPU. One additional interesting property of Qt glyph caching is that once you want to render text having a size that was not cached previously, something in Qt takes 5ms to setup, which is insane...

BTW one nice property of Blend2D text rendering is that when you use the multithreaded rendering context the whole text pipeline would run multithreaded as well (all the outline decoding, GSUB/GPOS processing, rasterization, etc...).

Post reply on HN