Skia: an open source 2D graphics library | Hacker News Reader

Skia: an open source 2D graphics library

skia.org

179 pointsstriking115 comments

Aseprite switched to Skia a year or so ago (https://github.com/aseprite/aseprite).

Regret it. Google doesn't care to maintain CMake support for it, so there goes pulling it in via source and building as a library dependency. https://github.com/aseprite/aseprite/issues/1598#issuecommen...

You may ask, "why don't you just write your own CMake module like everyone else?" I've tried. I think the build system changed a bit since, but back when I last tried, it required grabbing depot tools, checking out a source tree and a ton of other dependencies.

I am the original person that got Aseprite building on FreeBSD - but now I can't build it on any platform at all. Skia has too many points of failure in the build process. (Here's another issue where I spend hours trying to figure out what's going on https://github.com/aseprite/aseprite/issues/1081)

Every other graphics library (SDL2, Allegro, SFML) can work with CMake.

Another pain point: Skia isn't on any package managers to my knowledge. Here's the debian RFP https://bugs.debian.org/818180.

It's true. Google has essentially made it as painful as possible to use Skia outside of the google ecosystem. The build system is what's mostly kept me from using it in personal projects.

Xamarins wrapper for C# made it a breeze to use from C# at least - just add the package. The same is likely true for all ecosystems with reasonable package management. It’s only ironic that C++ libs are hardest to use from...C++

Sadly a consequence of the C culture that was adopted in C++ regarding how libraries should be distributed, before the time of package managers.

Just checked, and Skia is not to be found anywhere across vcpkg, Conan, Hunter, Ubuntu, Debian.

So using C# sounds much better than having to understand Google specific build processes to compile it.

I believe that... but the only reason why is they bent over backwards to come up with something that works today, and likely won't work in another 3 months, given the rate of turnover of build systems.

This must be Google's "strategy" for keeping people from profiting off of their open source code. I've encountered so many of their "open source" projects that are nigh impossible to build without having a Googler sitting in a chair next to you, walking you through all the unrecorded changes to the build process since the last time the documentation was updated.

Skia team here- We had an experimental cmake build that we let go last year, but sounds like there is more interest in it than we thought. It should not be hard to restore it, so we've got it on our todo list now.

Out of curiosity, aside from the obvious disadvantages you mentioned, what advantages does it bring to the table? Long-time casual user of Aseprite. To be honest, I never knew it was open source until just now, I actually own a couple copies.

Allegro, SDL2, SFML, et al. do more things (audio, joystick support, keyboard/mouse events) across platforms. Skia does one thing really well, 2D graphics.

There is a ticket open for building an abstraction layer @ https://github.com/aseprite/aseprite/issues/139

In terms of Aseprite:

> > But what made it the choice over Allegro 5, SFML, and SDL2?

> through all these years I reached to the conclusion that you need full control of mouse and keyboard messages (and all window messages in particular, e.g. to give proper support to pen/stylus). [1]

[1] https://github.com/aseprite/aseprite/issues/139#issuecomment...

OK, I agree with the sentiment. SDL2 is probably the closest to doing the right things, but even then you're on your own with the stylus APIs mostly.

So far, the only library I've used that can properly abstract graphics tablets across platforms is Qt, and in the past it has been sometimes rough around the edges with support for it. I think on Windows it is still using the Wintab32 API and not the newer Windows 8 Ink APIs, for example.

I’d be grateful to see some sort of build log from a successful run with this frankenbuilder and try making a traditional BSD Makefile.

With all the fuss with "modern" text editors built on top of web engines, I feel the need to remind you all that one of the fastest graphical code editors that I have ever used — SublimeText — was built using Skia for the rendering. I believe many people have noticed how smooth the interface and most of the operations feel, a very good selling point if you want to build a GUI in the future.

For xi-editor I considered Skia but ultimately decided to write my own OpenGL renderer. I think Skia would have worked, but the dependency was heavyweight and I'm able to tweak my renderer (for example, it gets linear-sRGB color blending right, while Skia uses an approximation). I have a draft blog post on this in the queue, but juggling just a few too many things at the moment.

Isn't skia able to call OpenGL too? Do you think your own thing will be lighter weight in the end? Which parts of skia do you think you won't need? (For sRGB, a patch for skia might be less work than a full new 2d library. Also depends on if your goal is to write fun code or to get a product out, of course.)

When leading an Android platform team several years ago, we enable the OpenGL backend to Skia to see if it would accelerate general UI rendering.

The conclusion was after a whole bunch of bug fixes (OpenGL ES 2.0 IIRC), it ran but (a) ate up a lot of GPU memory (b) was slower than the 2D rendering for 80% of the drawing operations (c) some rendering ops (such as the font wide) could not be easily accelerated, meaning you would need to flush the GPU partially rendered frame periodically, then bring into the CPU cache, draw over and then flush again before writing more GPU operations.

Fun experiment - poor outcome!

It all depends how you count. I consider the total cost of adopting a dependency the size of Skia to be quite a bit more than the lines of code written; I would have had to write _some_ code to do the interfacing. Then there's the question of source code download size and clean build times, which would have both gone up by more than an order of magnitude.

If I understod correctly (which isn’t certain) Skia is also the rendering backend for chromium. Chromium is used as the rendering bits for electron. Electron is how you make these apps on “web engines”. So all those editors based on web engines likely render through Skia...

Skia is one part of Chromium; you also have Blink (browser engine) and V8 (js engine).

Skia is also used by Firefox on some platforms (I think Linux/X11 and Android?) as its graphics backend.

But not with Webrender that's coming in Firefox 59 I suppose?

WebRender is not even enabled by default in Nightly yet. It’ll still be a while before it’s ready for production—definitely not Firefox 59. I don’t know of any schedule, but I haven’t been following it much either.

But yes, the Quantum Render project is all about making WebRender Firefox’s primary graphics backend.

Somehow I remember it was supposed to be Firefox 59, not sure where I saw it now. Of course it can slip if it's not ready.

I believe the target was Firefox 59, but they didn't make it.

I believe Skia was originally used in Android as well.

Isn't it still the case ?

You believe correctly.

You should have a look at 4Coder: https://4coder.handmade.network/

Currently targeting the C++ language. The guy is writing it in C++ and is targeting Windows & Linux. I think he's using openGL.

Even on Linux it's best. Tooltips suck a bit compared with those Electron editors.

For anyone thinking of skipping looking at this one. I was not interested either until I read this part:

> It serves as the graphics engine for Google Chrome and Chrome OS, Android, Mozilla Firefox and Firefox OS, and many other products.

Similar situation to the freetype/harfbuzz all-but-Microsoft/Apple (open source) monoculture.

I'm interested to understand more about how some categories of software libraries don't foster multiple strong open source alternatives, while others do.

I was thinking about this recently. I think this type of consolidation starts to make sense if you think of software as mathematics. A formula gets devised, iterated upon and refined, adopted, and then finally built upon.

It makes more sense to adapt a standard formula to a given use case than it is to derive a custom formula from the ground up. I suspect the reason why its not the case for software is because of copyright and IP laws.

Likewise, I expect mathematics wouldn't have advanced as much as it has had there been IP laws enacted for mathematics. People would too limited by the licensing terms for their Leibniz™ and Euler™ formulas to be able to be able to build the next step.

There are many degrees of freedom to work on when it comes to mathematics, many perspectives to look at the same problem. Some are elegant, some are ugly, others are painful to work with, and make future progress hard. Just as it is with software. We constantly need to reassess our foundations, and not get too coupled to a single perspective, lest it drive us into a corner and stifle further innovation.

Text rendering and layout is hard. There are few open source Freetype competitors, but they are all lacking compared to it. Same for HarfBuzz, though the alternative I know of are either dormant or abandoned.

Sublime Text afaik.

Ugh... This build system is _horrible_.

bash-dependent meta-builder for ninja-build working in git checkouts. Are both actual releases and traditional build systems that out of fashion?

You guys are killing me. After downloading twenty-some git repos(?) as dependencies (most of which my system already has), this (I’ll try to quit complaining about this better mousetrap now):

kamloops$ gn Traceback (most recent call last): File "/home/bch/work/skia/src/vendor/depot_tools/gn.py", line 38, in <module> sys.exit(main(sys.argv)) File "/home/bch/work/skia/src/vendor/depot_tools/gn.py", line 22, in main bin_path = gclient_utils.GetBuildtoolsPlatformBinaryPath() File "/home/bch/work/skia/src/vendor/depot_tools/gclient_utils.py", line 749, in GetBuildtoolsPlatformBinaryPath raise Error('Unknown platform: ' + sys.platform) gclient_utils.Error: Unknown platform: netbsd8

> After downloading twenty-some git repos(?) as dependencies (most of which my system already has)

Skia statically links in copies of these dependencies for testing purposes only. There is a mode ("is_official_build") that will search for your system libraies.

Ah. I used that flag on first build attempt (which failed), then did a “tools/git-sync-deps” to pacify the build system (w/o any flags), wherein the repo cloning did commence.

Fun fact, it is used in Android, but not exposed to the NDK.

So C++ applications on Android that wish to use Skia, do have to use the Java API via JNI (android.graphics.Canvas) with the respective performance impact due to marshaling, or package their own Skia version, thus increasing their APK size and having to deal with a build system that only makes sense for Google employees.

This can't be intentional, right?

Google does not seem interested in making the NDK anything more than implementing Java native methods, 3D graphics, audio or porting code from other platforms.

Everything else should be done at Java level.

I understand from the point of view of security, but what is safer, provide bindings to libraries already validated and installed on the device or forcing devs to package something else?

Also even though they implement native APIs in nice C++ with RAII and stuff, it gets exposed as unsafe C APIs, so the security story isn't 100% correct.

Java APIs ARE C APIs, for obvious reasons. There doesn't have to be any difference in security.

It is quite normal and traditional though, for C/C++ developers to work with what they call statically built binaries. They're a bit bigger (may God provide mercy, and huge amounts of free diskspace to those fools that enable debug), but the odds of them working flawless on a given device are much higher.

> Java APIs ARE C APIs,

You lost me there. I wouldn't call JNI boilerplate a C API.

> It is quite normal and traditional though, for C/C++ developers to work with what they call statically built binaries.

Polyglot dev here, including C and C++.

The way a library is linked is orthogonal to be made available on the SDK.

Skia does not have a stable ABI, which is a requirement for inclusion in the NDK: https://github.com/google/skia/blob/master/experimental/c-ap...

It has a stable API for Java clients on Android, if Google actually would care they could expose that one.

And in any case, creating a 2D abstraction layer stable API on top of platforms specific version APIs, specially given that all NDK APIs are C based even if written in C++, it is not rocket science, rather a matter of wanting to do it.

Also there is a Rust adapted version https://github.com/servo/skia, used on Servo

For a few things. These days most of Servo rendering is done on the GPU by WebRender. I think we only use Skia for canvas right now.

Hopefully we'll drop it altogether once Pathfinder is completed.

Will it be possible for others to use webrender/Pathfinder similar to Skia or Cairo? Or is it pretty connected to servo?

Not sure about Pathfinder but WebRender for sure, it's already usable outside of servo. People are attempting GUI toolkits and other things.

Unfortunately, this seems to be quite out of date.

Among all the other things mentioned in the comments, AFAIK this is the rendering engine for https://flutter.io/ too

Which means it's also used in most Fuchsia projects.

I've used it to create a desktop port of http://diep.io/. It's great (easy to use, reasonably documented), but it's a pretty big dependency (I don't remember exactly, but I think like 20 MB or so?). Since diep.io uses the canvas 2d API, porting was pretty straight forward. The performance on desktop is unsurprisingly many times faster than the browser.

What motivated your choice of Skia over WebGL?

You mean canvas 2d? If you're making a 2d game, it's good enough and looks really nice. Performance is good enough in most cases. Because of some OpenGL gotchas in some drivers (macOS mostly), some operations are a lot slower in those OSes (I have a demo that runs at 3 fps on my macbook, and >144 fps on my windows). It's easier to use canvas 2d as you don't have to deal with any of that.

There are alternatives to Skia that are even faster like FastUIDraw.

https://www.x.org/wiki/Events/XDC2016/Program/rogovin_fast_u... https://github.com/intel/fastuidraw

This looks really useful! Does anyone know how this compares to something like Cairo?

Skia (via SkiaSharp) is the rendering backend for my vector graphics diagramming application (https://vexlio.com). I chose it in part because it had much better performance than Cairo when I was testing both. Also the MIT license was more appealing to me than Cairo's LGPL or Mozilla Public License.

Looks like a nice project. For my own (web development) kind of projects I love to diagram infrastructure, Classes, etc.

But, I do nearly all my work on Linux -- which is a pity because I'd love to try out a tool like Vexlio.

For now I guess I'll continue to stick with yEd, because it actually works everywhere (java works).

Site looks great; well done!

That's the first question that occurred to me so I web-searched.

Seems it is faster and has a broader API. I sort of expected that Raph Levien(1) might have contributed or that Cairo would be part of the base of Skia. But apparently not.

(1) works at Google and wrote Cairo

I did not write Cairo, I wrote libart, and that was a long time ago. I'm good friends with several of the Skia authors, but don't actively work on it myself.

Oh, thanks for the correction.

Note that Skia is a C++ library and does not provide a stable C API.

Skia has a C API under development that is our approach to API stability, but it is not comprehensive and still being added to (sometimes by our clients to get access to the APIs they need).

There is also a .NET binding for Windows and Xamarin: https://www.nuget.org/packages/SkiaSharp/

We do lots of markup/drawing/overlay apps using Xamarin and SkiaSharp (SKCanvas/SKCanvasView/SKBitmap).

Skia is a great library. Pretty fast across UWP, Android, iOS and nice to have a common cross platform one that works well across most platforms (UWP, Win, Mac, iOS, Android).

UWP combined with Windows Ink (InkCanvas) is fun stuff.

Has anyone used this? Are there any examples?

We used it for our image rendering server, and it worked really great at the beginning. The library is fast, and the API was easy to use, and it worked on Azure App Service without issues.

We eventually abandoned Skia though because it only operates with premultiplied alpha. Works ok if you render on opaque surfaces, but we needed to generate transparent PNGs, and in the allotted timeframe couldn't resolve some rendering differences.

I’m converting a large desktop (CAD) app from GDI+ to SkiaSharp at the moment. Really liking the Api and the quality of the C# wrapper. Also maps very well to GDI concepts so a conversion is fairly painless.

Cool. Are you able to share any more details? I'm guessing this isn't a standard WinForms app. What advantages does moving away from GDI+ give you?

It’s a winforms app, and there isn’t much nonstandard about it other than that large performance sensitive drawing apps are perhaps quite nonstandard to begin with. We want to handle some large cad scenarios in it (e.g smooth pan/zoom in drawings with 500k lines), it’s not the default use case, but it happens. The main advandtage over gdi+ ) is better support for retained mode drawing (record/playback style drawing), more efficient automatic culling, etc.

Why are you converting to SkiaSharp, if I may ask? Is it for performance or multiplatform reasons?

See my answer on the other msg

Cool, how does it compare to Win2D?

It’s just a lot less ”different”. Performance is pretty similar across all frameworks, and is much more dependent on call patterns than anything else.

There are some examples in the source tree here: https://github.com/mono/SkiaSharp/tree/master/samples

The rather awesome, cross-platform, Microcharts (https://github.com/aloisdeniel/Microcharts) is built on top of SkiaSharp.

It's used as one of the backends for Avalonia UI https://github.com/AvaloniaUI/Avalonia/blob/master/readme.md

(Not affiliated but I love this project. If it wasn't still alpha I'd use it for absolutely everything)

How about font rendering? Would I use freetype/harfbuzz with this? They're such a bitch to build on Windows. Currently I'm using DirectWrite but having portability would be a nice bonus, as it seems that the API of this isn't worse than Direct2D.

The Firefox and Servo team are currently hard at work on Pathfinder, which should solve this for both fonts and SVG. It'll run on the GPU like WebRender which is super exciting: https://github.com/pcwalton/pathfinder - alas it's still a WIP at the moment.

That's very interesting, didn't know about this. It seems like it'll take substantial time for this to stabilize though. But still, something to revisit next time I'm evaluating options.

freetype and harfbuzz don't draw text. Freetype reads font files and gives you individual glyphs, and harfbuzz does "shaping". Pango does layout but also doesn't draw text.

I know, which is why I said 'font rendering' - but of course (for any practical purpose) that extends into drawing onto a context/canvas/whatever it's called in a specific ecosystem. Pango can draw to Cairo (modulus some very pedantic definitions of 'draw'), for example, but in some combinations of glyph rendering/layouting/drawing libraries you have to fiddle with getting one library to render as a path and then use generic path drawing routines to actually rasterize. I can't be bothered with that sort of minutiae, hence my question - how much (if at all) is this library integrated with other functionality to render, query the rendered form, and rasterize text.

I mean, say what you want about DirectWrite and the Direct2D environment - but at least it's very clear how things fit together and it works very well, even for niche use cases. In open source land, you spend days just puzzling together the pieces - let alone build them and getting them to actually do something useful from code. I've tried plenty over the last 15 years.

(edit: typos)

C++ 11, nice. Does anyone use this? And if you do how does it compare to alternatives

Skia is probably the most popular 2D graphics library at the moment. I don't really know why this got on HN now. It's already extremely popular.

I use it in a little WIP game engine. It's very pleasant, excellent little library. There's an online jsfiddle-esque demo here https://fiddle.skia.org/ if you want to try it out.

The funny thing is that Skia is a startup in NC that was acquired more than a decade ago and turned into one of the smallest and most elusive Google engineering offices, basically just to keep Mike Reed (TrueType and TrueType GX) and his people.

The original “Skia” was the development name for QuickDraw GX[1]. (I don’t know why the Wikipedia page doesn’t say that any more.) Cary Clark, who now works at said “elusive Google engineering office”, was the mastermind behind that Skia. TrueType was a sibling project; we (QuickDraw GX team) collaborated closely with them.

Mike’s AlphaMask (sold to OpenWave) didn’t share code with the original Skia but was kind of a Skia 2, with more flexible and clearer architecture than the original. This Skia—which, again, doesn’t share code with either of its predecessors—is a kind of version 3, with a tribute name back to that original Skia.

[1]: https://en.wikipedia.org/wiki/QuickDraw_GX

Been one feet in the gamedev space for pretty much my whole teenage and adult life, and it's the first time I've heard about it. It might be me just not paying attention, or maybe it's not that popular for end-users.

You could use it inside your custom game engine, but it wouldn't make much sense. Most 2D games work with bitmaps and sprite-sheets and Skia gives you full vector graphics. It's huge dependency, inflates your executable by few tens of megabytes and still doesn't give you window management and input handling and so on. SDL is still the king here - it provides just enough to build upon in reliable and cross-platform fashion.

Skia would be more useful for graphical applications focused on vector graphics (diagrams, plots, layout editors, CAD...). And for general purpose 2D graphic platforms like browsers have.

I have a little 2d game that I'd like to port over to Skia. What did you end up using to handle input and audio and other gamey things?

I would think SDL would be an easy cross-platform choice there.

You might look at https://sciter.com/ Which apparently uses Cairo, Direct2D or Skia depending on the platform.

I used https://github.com/jkuhlmann/gainput for input. I never did get around to handling audio.

For the UI I used imgui. Skia actually comes with an imgui backend (it's used for the Viewer tool) that is easy enough to hack into whatever you need.

Nice but got "Failed to run, possibly violated security container"

The little server that runs fiddle.skia.org is probably overloaded.

Not sure where it is popular.

Even I rather use SDL, written in C, than having to deal with getting to compile Skia across my platforms.

Then there is Cocos2d-x, SFML and OpenFrameworks as well.

How many Android devices are out there right now? They've all been using Skia since day one.

It is not exposed to native code.

What's realtime perf like?

> It serves as the graphics engine for Google Chrome and Chrome OS, Android, Mozilla Firefox and Firefox OS, and many other products.

Skia is used by Chrome, Android, and Flutter at Google. I believe Adobe and Microsoft also use Skia in various products.

Doesn’t Microsoft have Direct2D for this sort of thing.

I think it's for Xamarin.

SublimeText uses Skia for rendering.

Google Chrome

Somehow the text it renders looks worse than all the other common graphics libraries on Linux - which all use FreeType and Harfbuzz. I am not sure what QtWebEngine does differently, because it uses Blink and the text looks fine.

"looks worse" is a pretty nebulous statement. Can you go into detail? Do you think text in Chrome looks bad?

It seems like lack if subpixel rendering plus the spacing between letters is somehow screwed. Really hard to put a finger on it, it just looks wrong to me. I do think that text in Chrome looks bad on Linux. I could compare magnified screenshots now but I'm too lazy, sorry. Don't care much about Chrome anyway.

How good/hard to build an UI library (like bootstrap) on it? I'm already on F#/C# so I don't will have issues with building it (I imagine!)

So back in the early 90s Apple had a graphics library called "skia" - are these related?

See this post from earlier: https://news.ycombinator.com/item?id=16148185

The roadmap needs to be updated. It's for 2016-2017.

It has been updated with the doc of high level themes we are chasing for 2018.

just a heads up, skia doesn't work on big endian.

Reply on news.ycombinator.com