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

91–100 of 181 posts

Re: WebKit switching to Skia for 2d graphics rendering

#91

Post by zozbot234 »

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.

Re: WebKit switching to Skia for 2d graphics rendering

#92

Post by mort96 »

yetihehe wrote: post #78
jb1991 wrote: post #63

Earlier quoted context omitted.

Nothing happened to it. It’s just slow.

It's not that slow, I was amazed by performance when I first used it, but maybe other libs are even faster.

It's perfectly decent for a CPU renderer, CPU rendering is just slow.

Re: WebKit switching to Skia for 2d graphics rendering

#93

Post by [deleted] »

kaba0 wrote: post #85
incrudible wrote: post #67

Earlier quoted context omitted.

The bytecode compilation doesn't really matter, it's still gonna jank. Maybe not as badly, but it will. The only way to get rid of jank is to cache not the bytecode and not even the native code, but the PSOs. Realistically, that is only possible on the target machine, unless you have a ginormous farm of machines representing all the permutations of hardware and drivers. That's basically what Steam does with its mass…

Could you please tell me what PSOs are? I am not sure I found the proper abbreviation.

[deleted]

Re: WebKit switching to Skia for 2d graphics rendering

#94

Post by jupp0r »

twic wrote: post #84
pcwalton wrote: post #47

Earlier quoted context omitted.

The difficult parts change all the time and usually boil down to some sort of undocumented or poorly-documented dependency, especially if you're trying to enable the GPU backends. Every time someone I know tries to get it building it takes them a week to figure out how to do it.

Does Skia have a continuous build somewhere? Is there any way to piggyback off the config for that? I found this: https://github.com/google/skia-buildbot Assuming that the Skia maintainers keep that working, it might be easier to build the buildbot and use that to build Skia, than to build Skia directly!

Yes, it's built as part of Chrome IIRC.

Re: WebKit switching to Skia for 2d graphics rendering

#95

Post by jupp0r »

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

Re: WebKit switching to Skia for 2d graphics rendering

#96

Post by jwells89 »

jsheard wrote: post #41
londons_explore wrote: post #38

Blink, Chromiums rendering engine, based on WebKit, already uses skia right? Why not just import all that code?

Blink split from WebKit a decade ago, I doubt they still have enough in common for it to be worth merging features.

Particularly with Blink being entirely reliant on Chromium for multiprocess, whereas WebKit handles multiprocess itself. This was actually one of the issues that spurred Blink’s forking and entails significantly different architectures.

Re: WebKit switching to Skia for 2d graphics rendering

#98

Post by yetihehe »

mort96 wrote: post #92
yetihehe wrote: post #78

Earlier quoted context omitted.

It's not that slow, I was amazed by performance when I first used it, but maybe other libs are even faster.

It's perfectly decent for a CPU renderer, CPU rendering is just slow.

I had to make a map module for python desktop application , options were either embed full browser inside and use google maps, or do it myself. C module using cairo was MUCH faster and easier to achieve in 2013. So much faster I didn't have to implement some optimizations I planned because it was already running at about 50fps on average computers with ~1000 individually drawn markers on a map. Requiring any gpu for this was not possible anyway.

Re: WebKit switching to Skia for 2d graphics rendering

#99

Post by DrScientist »

jenadine wrote: post #76
DrScientist wrote: post #74

Earlier quoted context omitted.

Not an expert on graphics libs - but I did notice that the Google project Flutter is moving away from Skia to something new called Impeller. https://medium.com/@gauravswarankar/flutter-will-use-an-impe...

I believe Impeller is even worse with regards to all the issues mentioned in the parent comment. In particular since it is so tight to Flutter.

I get the point about it being developed with one primary objective - but perhaps a naive question here - in the end isn't that primary objective a shared one - to render text, lines, curves and images as fast as possible, via some sort of higher level API?

And to do so onto multiple OS & hardware backends?

Re: WebKit switching to Skia for 2d graphics rendering

#100

Post by WorldMaker »

DrScientist wrote: post #99
jenadine wrote: post #76

Earlier quoted context omitted.

I believe Impeller is even worse with regards to all the issues mentioned in the parent comment. In particular since it is so tight to Flutter.

I get the point about it being developed with one primary objective - but perhaps a naive question here - in the end isn't that primary objective a shared one - to render text, lines, curves and images as fast as possible, via some sort of higher level API? And to do so onto multiple OS & hardware backends?

It's the old coupling versus cohesion problem, isn't it? The tighter the coupling the more likely that abstractions leak across API boundaries. The tighter the monorepo the less likely there's a concerted effort to avoid breaking changes and consider long term API stability.
Post reply on HN