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