[HN Gopher] WebKit switching to Skia for 2d graphics rendering
___________________________________________________________________
WebKit switching to Skia for 2d graphics rendering
Author : jessevdk
Score : 305 points
Date : 2024-02-20 07:46 UTC (15 hours ago)
(HTM) web link (blogs.igalia.com)
(TXT) w3m dump (blogs.igalia.com)
| valleyer wrote:
| "WebKit Switching to Skia for 2D Graphics Rendering"
|
| ... for the GTK and WPE ports. Not on Apple platforms.
| 01HNNWZ0MV43FF wrote:
| Oh. I thought all web browsers were on Skia now.
|
| I guess the Apple platform is CoreGraphics and GTK was Cairo?
|
| (Edit: Read the article. Yes)
| tuankiet65 wrote:
| WebKit on Apple platforms uses Core Graphics and Core
| Animation, yes.
| the_common_man wrote:
| oh, title buried the lede there
| DANmode wrote:
| Brutal.
| ho_schi wrote:
| I think this are good news for _WebKitGtk_.
|
| 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 wrote:
| For others that didn't know about this advertising clause:
| https://www.gnu.org/licenses/bsd.html
| thrwwycbr wrote:
| 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)
| DennisAleynikov wrote:
| Awesome! Glad to see skia is finding uses in places other than
| fuschia
| paraboul wrote:
| Well, it powers web rendering in Chrome
| pavlov wrote:
| And Android graphics...
| mort96 wrote:
| And Canvas in Firefox...
| refulgentis wrote:
| And Flutter on Canvas
| jdthedisciple wrote:
| And some rendering libraries in .NET
| ceronman wrote:
| And the new UI framework for Jetbrains Fleet. And the new
| UI framework for Clojure Humble UI
| Doctor_Fegg wrote:
| All right, but apart from the sanitation, the medicine,
| education, wine, public order, irrigation, roads, a fresh
| water system, and public health, what have the Romans
| ever done for us?
| tester457 wrote:
| And gamedev sprite editing with Aseprite
| jahnu wrote:
| And there was work in the Chromium PDF library, pdfium,
| to switch to SKIA from AGG. It was going slowly for many
| years and wasn't finished last time I looked about three
| years ago.
| quaintdev wrote:
| Correct me if I'm wrong but I think Flutter also uses Skia for
| rendering UI
| emersion wrote:
| FWIW Flutter is now moving sway from Skia, they are migrating
| to a dedicated custom GPU renderer (Impeller).
| andy_ppp wrote:
| It works wonderfully well for my react native app, see
| https://shopify.github.io/react-native-skia/ for details!
| cryptos wrote:
| Skia is also used by "Compose Multiplatform" by JetBrains.
| https://www.jetbrains.com/lp/compose-multiplatform/
| grufkork wrote:
| VVVV uses it too!
| a1o wrote:
| And VVVVV doesn't! :)
| bj-rn wrote:
| In case anyone is wondering: visualprogramming.net
| chadcmulligan wrote:
| Its the optional rendering engine in Delphi's cross platform
| framework (fire monkey) now to.
| surajrmal wrote:
| Note that skia is only ever used on fuchsia for flutter. It
| shares that dependency on skia for all platforms it targets
| (which haven't otherwise been migrated to impeller).
| ComputerGuru wrote:
| I guess it won't be used any more since, as discussed
| elsewhere in the comments, Flutter has moved from Skia to
| Impeller.
| andsoitis wrote:
| > but none of them met all our requirements, so we decided to try
| writing our own library.
|
| Question requirements.
|
| You can always find a reason to build rather than buy, but can
| you reframe your requirements in such a way that you can get away
| with something off the shelf and then rather spend your resources
| on the things that you can do uniquely different for your
| application.
| mort96 wrote:
| I mean I really don't know what library they could've tried
| other than Skia that's suitable to build a GPU renderer for
| Canvas's API, and they explain why they were hesitant to try
| Skia. Do you have any suggestions?
| marwis wrote:
| Mozilla's WebRender. It's actually a better option by their
| own criteria because it's developed as a standalone reusable
| library.
| mort96 wrote:
| Oh I read the article with the assumption that this was 2D
| _canvas_ rendering, but upon re-reading it I see that it 's
| probably about normal web content. WebRender would've been
| a terrible fit for Canvas, but it would certainly make
| sense if this is about rendering normal web content.
| thrwwycbr wrote:
| Maybe try to build your own Browser and try to keep up with
| upstream that has daily changes in the hundreds of
| commits...and then realize how elitarian that answer was?
|
| They are a software product fork used by billions, with a team
| that doesn't get paid to develop on it, with not enough funding
| to just "buy" a battle tested library which has zero problems;
| because any bug would literally potentially break the web for
| years.
| tapirl wrote:
| So will they maintain a stable C API to skia?
|
| It is long-time known pain point that the skia official doesn't
| provide a usable C API.
| mort96 wrote:
| Why would they? The API they (WebKit) are providing is the
| Canvas API, the fact that they're using Skia behind the scenes
| is an implementation detail... I don't see why they would go
| through the trouble of maintaining a stable C API for internal
| use in a C++ project?
| cylemons wrote:
| Maybe so they could use newer versions of skia
| mort96 wrote:
| This assumes that maintaining a stable C interface to Skia,
| and then writing the WebKit rendering code against that C
| interface, is easier than maintaining WebKit rendering code
| which calls Skia's C++ interface directly. I'm not
| convinced that that's the case.
|
| At the very least, the stable interface should probably be
| C++, mapping between C and C++ is often non-trivial...
| londons_explore wrote:
| One way to keep a stable API is to pin the version used...
|
| And let's be honest, the external API doesn't change awfully
| fast anyway. A totally dead project would fall behind, but even
| a tiny amount of work would be able to keep up.
| feverzsj wrote:
| I think only Microsoft maintains a stable C API for their
| SkiaSharp. Skia only cares about google projects. I don't even
| know why they bother to opensource it.
| surajrmal wrote:
| Open source doesn't mean there are any obligations. It's
| surprising how we don't see more of this. I imagine Google
| wouldn't even bother with making the source available if
| there was an obligation attached.
| vthommeret wrote:
| 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...
| infogulch wrote:
| Igalia is also working on Servo.
|
| https://news.ycombinator.com/item?id=37430579
| spaniard89277 wrote:
| It's in my city. Their offices are just a small flat in in a
| pretty bland neighborhood. I guess most of them work remote.
| TingPing wrote:
| 82% remote :) (Not counting those that live in the city but
| are still WFH)
| thrdbndndn wrote:
| 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 backed up by large companies.
| TingPing wrote:
| 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.
| thrdbndndn wrote:
| Ah thanks, that clears it up.
| leonheld wrote:
| Igalia and Collabora seem like pretty interesting places to
| work if you're doing open source. I've seen nothing but good
| come coming from there.
| zerr wrote:
| Didn't Flutter ditch Skia recently due to performance reasons?
| canucker2016 wrote:
| Yes, from 2023 Jul 21 blog entry,
| https://medium.com/@wartelski/impeller-rendering-engine-is-i...
| :
|
| "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."
| charcircuit wrote:
| >Unlike Skia, Impeller compiles shaders during the build
| process instead of at runtime.
|
| This wouldn't work on most platforms as graphic driver
| updates can break compatibility with previously compiled
| shaders.
| jsheard wrote:
| There's often multiple compilation steps, first compiling
| some application specific representation down to
| HLSL/GLSL/MSL source code, then compiling that down to
| DXIL/SPIRV/Metal bytecode, and then handing that off to the
| driver for compilation to native code. The first two steps
| at least can be done ahead of time, the bytecode is stable.
|
| Metal and CUDA actually let you AOT compile native binaries
| since they have relatively few hardware targets to support,
| with a fallback to compiling bytecode to native at runtime
| for forwards compatibility.
| incrudible wrote:
| 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
| of users.
|
| The alternative is to just not have _that many_ shader
| permutations, and potentially take a performance hit from
| that. This seems to be the strategy that Impeller is
| following.
| kaba0 wrote:
| Could you please tell me what PSOs are? I am not sure I
| found the proper abbreviation.
| perlclutcher wrote:
| PSO = Pipeline State Object
| max_ wrote:
| Hi guys, I have a question. What is the 3D equivalent to Skia?
| rice7th wrote:
| I guess there's no such thing. It's probably going to be raw
| opengl or something; 3D graphics is A LOT more complex than 2d
| graphics
| longor1996 wrote:
| bgfx and The-Forge come to mind:
|
| https://github.com/bkaradzic/bgfx
|
| https://github.com/ConfettiFX/The-Forge
| krona wrote:
| 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.
| londons_explore wrote:
| I've only briefly looked at skia internals.... And it's awfully
| complex!
|
| But the external API is fairly simple. Basically you queue up
| various drawing commands and at the last minute tell it to
| execute the queued commands somewhere.
|
| The queue is 'optimized' - for example if you tell it to draw
| some text and later crop the text out of the image, then no
| CPU/GPU time will be spent drawing text that won't be visible
| in the output. You can also draw text small and scale it up
| later without getting jagged edges as you would if you'd scaled
| up a raster image.
|
| That ability lets you make tile based renderers, where you
| queue up all the commands for say a whole webpage, but then
| draw only a small square of the page like a map tile, and as
| the user scrolls/pans, you can draw more tiles as needed.
| coffeeaddict1 wrote:
| 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.
| danpalmer wrote:
| 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?
| pcwalton wrote:
| 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.
| Lutger wrote:
| I used to do that when I started out with C/C++...15 years
| ago. Now my patience is running out after 10 minutes.
| Tooling has become so much better, but it seems not that
| much with some C/C++ projects. At least the build times are
| better, I remember big libs would could take hours to
| build.
| ho_schi wrote:
| _Meson_ and _ninja_ improved a lot in this area for C
| /C++.
| twic wrote:
| 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!
| jupp0r wrote:
| Yes, it's built as part of Chrome IIRC.
| rstat1 wrote:
| Took me less than an hour to figure out how to build it
| just reading the instructions they have on their website
| for building.
|
| Skia really isn't that hard to use IMO even for GPU
| accelerated stuff.
| wokwokwok wrote:
| > In my experience CMake isn't exactly a great developer
| experience
|
| o_O unlike GN?
|
| Have you used it much?
|
| https://gn.googlesource.com/gn/
| danpalmer wrote:
| I haven't used GN, I'm mostly thinking of Bazel, but was
| also just interested in the specifics.
| rstat1 wrote:
| Yes GN IMO is a much better experience than CMake. Its
| fully self-contained in a single binary that you can easily
| just distribute with your code. I have a small python
| script I use with it to regen files, and then to run Ninja
| to do the actual builds.
|
| I've been using it for years and have no complaints.
| pcwalton wrote:
| 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.
| tjpnz wrote:
| In 2024 it would probably be faster to hire a xoogler.
| dkjaudyeqooe wrote:
| > 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.
| gigatexal wrote:
| What happened to Cairo the 2d graphics tool?
| jb1991 wrote:
| Nothing happened to it. It's just slow.
| yetihehe wrote:
| It's not that slow, I was amazed by performance when I
| first used it, but maybe other libs are even faster.
| mort96 wrote:
| It's perfectly decent for a CPU renderer, CPU rendering
| is just slow.
| yetihehe wrote:
| 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.
| gigatexal wrote:
| Can it be GPU accelerated? (Is that even a dumb question to
| ask?)
| tetromino_ wrote:
| 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.
| Asm2D wrote:
| GPU support was removed from Cairo, because it was slower
| than CPU rendering and nobody wanted to maintain it.
| tetromino_ wrote:
| Cairo's OpenGL support was removed, but I thought Cairo's
| X11 backend still has GPU acceleration for a few
| operations through XRender (depending on your video
| driver).
| Asm2D wrote:
| That's true, Cairo still provides XRender backend. Not
| sure it's that usable though as I think nobody really
| focuses on improving XRender, so it's probably in the
| same state as Cairo itself.
| Asm2D wrote:
| Cairo is in a maintenance-only mode. Nobody develops this
| library anymore and it only has a maintainer or two. Since
| nobody really worked on Cairo in the past 15 years it's not
| optimized for modern hardware.
|
| You can see some existing benchmarks here:
| - https://blend2d.com/performance.html
|
| Both the benchmarking tool and Blend2D are open-source
| projects so anyone can verify the numbers presented are
| indeed correct, and anyone can review/improve the backend-
| specific code that is used by the benchmarking tool.
| hgs3 wrote:
| > Cairo is in a maintenance-only mode.
|
| That's too bad. Is their a successor planned or is Skia
| the recommended alternative?
| Asm2D wrote:
| I think that when it comes to 2D rendering libraries
| there is in general not too many options if you want to
| target CPU or both CPU+GPU. Targeting GPU-only is bad for
| users that run on a hardware where GPU doesn't perform
| well or is not available at all due to driver issues or
| just not present (like servers).
|
| If you consider libraries that offer CPU rendering there
| are basically: - AGG (CPU only)
| - Blend2D (CPU only, GPU planned, but not now)
| - Cairo (CPU only) - Qt's QPainter (CPU only,
| GPU without anti-aliasing / deprecated) - Skia
| (CPU + GPU) - Tiny Skia (CPU only, not focused
| on performance) - GPU only libs (there is many
| in C++ and Rust)
|
| Nobody develops AGG and Cairo anymore and Qt's QPainter
| hasn't really improved in the past decade (Qt Company's
| focus is QtQuick, which doesn't use QPainter, so they
| don't really care about improving the performance of
| QPainter). So, only 2 libraries from this list have
| active development - Blend2D and Skia.
|
| As an author of Blend2D I hope that it will be a go-to
| replacement for both AGG and Cairo users.
| Architecturally, Blend2D should be fine after a 1.0
| release as the plan is to offer a stable ABI with 1.0 -
| And since Blend2D only exports C-API it should be a great
| choice for users who want to use every cycle and who want
| their code to work instead of making changes every time
| the dependency is updated (hello Skia).
|
| At the moment Blend2D focuses on AGG users though,
| because AGG is much more widespread in commercial
| applications due to its licensing model and
| extensibility. However, AGG is really slow especially
| when rendering to large images (like 4K) so switching
| from AGG to Blend2D can offer a great performance
| benefits while avoiding other architectural changes of
| the application itself.
|
| BTW Blend2D is still under active development. It started
| as an experiment and historically it only offered great
| performance on X86 platforms, but that is changing with a
| new JIT backend, which provides both X86 and AArch64
| support and is almost ready for merge. This is good news
| as it will enable great performance on Apple hardware and
| also other AArch64 devices, basically covering 99% of the
| market.
| rubymamis wrote:
| Qt Quick should support non-GPU rendering[1]. I don't
| know how good it is, tho.
|
| [1] https://www.toradex.com/blog/running-qt-without-gpu
| a_e_k wrote:
| I'm the author of another CPU-only 2D vector graphics
| library that might be of interest:
|
| - Canvas Ity (https://github.com/a-e-k/canvas_ity)
|
| It's a tiny single-header C++ library in the style of the
| STB libraries. My aim was to make it dirt simple to be
| able to drop into almost any project and get high-quality
| rendering while providing an API comfortable to those
| used to <canvas>.
|
| I've been checking out Blend2D every now and then. It
| seems like a very nice option for the bigger, but faster
| and more fully-featured end of the spectrum.
|
| (Though for what it's worth, while raw performance isn't
| my priority, my little library still can hit about 70fps
| rendering the Postscript Tiger to 733x757 res with a
| single thread on my 7950x. :-)
| c-smile wrote:
| If I am not mistaken, NanoVG actually can render as by
| CPU (need external path rasterizer) as by GPU (OpenGL and
| other options).
|
| NanoVG provided Canvas.Context kind of API in plain C.
| pizza234 wrote:
| Some details in the article:
|
| > There was an attempt at making Cairo support GPU
| rendering, which did not work particularly well due to the
| library being designed around stateful operation based upon
| the PostScript model--resulting in a convenient and
| familiar API, great output quality, but hard to retarget
| and with some particularly slow corner cases. Meanwhile,
| other web engines have moved more work to the GPU,
| including 2D rendering, where many operations are
| considerably faster.
| fxtentacle wrote:
| 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 cores running at full speed.
|
| I believe the best way is probably to use Blend2D for
| rendering glyph bitmaps and then compositing them into the
| full text on GPU.
|
| Sadly, CPU memory is still plenty slow compared to GPU memory
| and when you need to copy around 100 MB images (4K RGB
| float), then that quickly becomes the limiting factor.
| Asm2D wrote:
| 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...).
| Asm2D wrote:
| Thanks! I'm doing what I can to make Blend2D even faster.
| It's been really exciting project to work on and I have big
| plans with this library.
| pas wrote:
| Have you heard about Vello (written in Rust)
| https://www.youtube.com/watch?v=mmW_RbTyj8c&feature=youtu.be
| ?
| pavlov wrote:
| 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.
| gcr wrote:
| Out of curiosity, why do you rebuild? What kinds of new
| features would get you to want to upgrade?
| pavlov wrote:
| The Skia C++ API changes quite a lot. If I didn't sync up
| regularly, the tech debt could become a problem down the
| line, for example if I want to add a platform that does
| need a new build of the library.
| creshal wrote:
| CVE-2023-2136 and friends are good reasons to upgrade.
| Calavar wrote:
| Have you considered Blend2D? It's much easier to build, and
| performance is on par with Skia.
| intblku32 wrote:
| I thought Blend2D was a CPU-only library. Skia offers
| hardware acceleration via the GPU.
| charcircuit wrote:
| 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.
| newaccount74 wrote:
| How long did downloading dependencies take? That's part of
| the build process.
|
| As a maintainer of a project that includes another popular
| library from Google, here's why it's difficult to build:
|
| - building requires downloading Googles custom toolchain and
| build system
|
| - dependencies are huge, so you have lenghty download times
| even on fast connections
|
| - it usually works if you are using a recent versions of OS
| and Python, but if you try running the same command in a year
| or two it might fail because they changed the requirements
|
| - if anything fails you have to dig through multiple levels
| of abstractions to figure out where it failed and why
|
| - if you want to maintain software for a few years, you'll
| have to keep fixing the build process because the build will
| suddenly stop working for unknown reasons once a year or so
| charcircuit wrote:
| >How long did downloading dependencies take?
|
| Around 5 minutes.
|
| >That's part of the build process.
|
| It's dependent on one's internet speed so I didn't think it
| made much sense to time it. If it took 20 to 30 minutes to
| download I would have mentioned it.
| mid-kid wrote:
| This doesn't reflect my experiences at all. I've never built
| it with bazel, are you sure it's not using some prebuilt
| binary?
|
| The official instructions are
| https://skia.org/docs/user/build/
| surajrmal wrote:
| It looks like they are several years into a migration to
| bazel and support both a bazel and gn based build. Bazel is
| usually faster. It's possible the gn based build builds
| everything in the repo including all tests, but the bazel
| one is more targeted, building less things
|
| https://skia.org/docs/dev/contrib/bazel/
| coffeeaddict1 wrote:
| It depends on what features you have enabled, how slow your
| internet connection is and obviously hardware/software
| config. On my 10th gen Intel i5 laptop 8gb ram (on Windows),
| it takes 15 minutes to build if I don't do anything else, but
| if I start using Firefox and IDEs, the build times are easily
| in the 20-25 minutes ballpark.
| jeffbee wrote:
| Using the official instructions, it took 4 minutes to scratch
| download skia and all its deps and build it with ninja. It
| only had 1235 build actions ... that's like zero.
|
| If this seems like a big lift, people are going to hate
| building Chromium.
| DrScientist wrote:
| 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...
| jenadine wrote:
| 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.
| DrScientist wrote:
| 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?
| WorldMaker wrote:
| 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.
| loic-sharma wrote:
| Skia relies heavily on runtime shader compilation, which
| is slow and causes frame jank but improves peak
| performance. Skia also supports much older devices than
| Flutter does.
|
| There's no free lunch, Impeller has a different set of
| trade offs that are a better fit for Flutter.
| zozbot234 wrote:
| > 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.
| nox101 wrote:
| Vello is used in Skia
|
| https://skia.googlesource.com/skia/+/2e551697dc56/third_part.
| ..
| djmcnab wrote:
| Disclaimer: I work on Vello[0], but not on the Skia
| integration directly
|
| My understanding, having not dug into it too much, is that
| the Skia integration does exist, but isn't enabled by
| default/any clients at the moment. That is, I don't know
| that this integration is shipping anywhere.
|
| Vello still has some definite rough edges at the moment, so
| I'm not sure I'd recommend using it in a production
| application at the moment. We also don't have a C API,
| which might rule it out for some cases where you'd be
| considering Skia.
|
| [0]: https://linebender.org/blog/xilem-2024/
| jupp0r wrote:
| 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.
| c-smile wrote:
| > 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/
| c-smile wrote:
| About premake5 in general.
|
| premake5 is a monolithic/portable executable that contains
| Lua + specific runtime.
|
| Thus it does not rely on installed Python as in GN case as
| other tools.
|
| Having standard and well known and documented Lua on board
| benefits the maker a lot. In my opinion any modern build
| system must include generic and known PL.
|
| And that above is the problem of modern CMake. It started as
| simple static declarative thing but life forced it to evolve
| into dynamic programming language with very strange notation
| and runtime model.
| sounds wrote:
| > it does not rely on installed Python as in GN case as
| other tools.
|
| I'm curious if you can expand on how you're using python,
| and what pain points you have there? I think python 3.9 was
| one for us but not too bad.
| adamjs wrote:
| 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
| grandinj wrote:
| This.
|
| 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 wrote:
| > I wish there was a nice and small vector graphics library
| with GPU acceleration.
|
| Check out nanovg: https://github.com/memononen/nanovg
| gct wrote:
| 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.
| londons_explore wrote:
| Blink, Chromiums rendering engine, based on WebKit, already uses
| skia right?
|
| Why not just import all that code?
| jsheard wrote:
| Blink split from WebKit a decade ago, I doubt they still have
| enough in common for it to be worth merging features.
| jwells89 wrote:
| 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.
| a1o wrote:
| 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...
| Sytten wrote:
| 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.
| TingPing wrote:
| 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.
| Wowfunhappy wrote:
| > I wish WebKit was [...] in the MDN compatibility list
|
| Are the capabilities substantially different from Apple webkit?
| TingPing wrote:
| 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.
| Wowfunhappy wrote:
| > There are a few big differences like WebRTC support isn't
| in WebKitGTK releases.
|
| Ah, thanks--I can see how that's the kind of thing you
| would want to see in a compatibility table!
| prosody wrote:
| Adding to this wishlist, if it were available on Windows then
| it would be an option for a cross-platform webview widget, but
| it hasn't supported it for a while now.
| prosody wrote:
| 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?
| JoelEinbinder wrote:
| 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.
| TingPing wrote:
| 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.
| leetrout wrote:
| 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.
|
| 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
| tadfisher wrote:
| There's also the GTK Scene Graph Kit[0], which just added GPU-
| accelerated path drawing and is shaping up to be a decent Cairo
| replacement.
|
| 0: https://docs.gtk.org/gsk4/
| mardifoufs wrote:
| Completely ignorant question: what's the issue with Cairo? I
| know it has had a hard time getting maintained but is there
| any article or blog talking about how it works or how it
| _doesn 't_ work? I've never used it directly but I'm super
| curious to know more !
| wffurr wrote:
| The op talks a bit about the limitations of Cairo.
| __s wrote:
| > There was an attempt at making Cairo support GPU
| rendering, which did not work particularly well due to
| the library being designed around stateful operation
| based upon the PostScript model--resulting in a
| convenient and familiar API, great output quality, but
| hard to retarget and with some particularly slow corner
| cases. Meanwhile, other web engines have moved more work
| to the GPU, including 2D rendering, where many operations
| are considerably faster.
| danielvaughn wrote:
| 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.
| lukan wrote:
| "I'm not sure if Rive's renderer is open source though."
|
| I did not follow Rive yet (but will do now), but it seems the
| renderer is MIT licenced, here the wasm/js renderer:
|
| https://github.com/rive-app/rive-wasm/blob/master/LICENSE
|
| Open source renderer would be the requirement for me to
| invest into it (not gonna fall for flash again).
| darzu wrote:
| 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].
|
| 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
| mrpippy wrote:
| The title should probably be "WebKit *on non-Apple platforms*
| switching to Skia..."
| spixy wrote:
| Wait there is still any WebKit on non-Apple platform?
| TingPing wrote:
| WebKit is probably the most common embedded engine. From game
| consoles to kitchen appliances.
| satao wrote:
| yep. I used to develop web applications for smart
| televisions and we just targeted webkit
| vfclists wrote:
| FFS why are the fonts so small?
|
| Why do I have to increase the font size 150% to read it
| comfortably?
|
| How can we trust a browser created by developers who seem
| incapable of creating readable web pages?
|
| They should be capable of dogfooding their own output on the most
| basic level.
| unleaded wrote:
| you know what website you're writing this on?
| maattdd wrote:
| The title of the article has changed to make it clearer than it
| only concerns the GTK and WPE ports.
|
| "WebKitGTK and WPEWebKit Switching to Skia for 2D Graphics
| Rendering"
|
| Can we update the title here also?
| rezmason wrote:
| I really like how much utility we've all managed to get from
| Cairo. It is everywhere.
|
| 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.
| miohtama wrote:
| 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.
| TheTon wrote:
| This post seems to be just about the GTK port of WebKit. So
| they're comparing Skia vs Cairo on Linux. There's no mention of
| Skia vs CoreGraphics for macOS. It doesn't sound like that is
| something that is being considered.
| pipeline_peak wrote:
| > Safari adopts Google library
|
| And so it begins...
| ComputerGuru wrote:
| Nothing to do with Safari.
| pipeline_peak wrote:
| True, but how does this draw any concern away from Google
| having a major control in browser usershare?
| simscitizen wrote:
| Who simplified the title here? This is only for the GTK and WPE
| ports of WebKit. Not for other platforms that WebKit supports.
| Jarred wrote:
| Is this for all of WebKit or the non-Cocoa/Apple builds? It reads
| like WebKit on Mac (Safari) will not be impacted by this change
| mortallywounded wrote:
| I had to build Skia once in order to build Aseprite from
| source... I gave up and bought Aseprite instead.
___________________________________________________________________
(page generated 2024-02-20 23:00 UTC)