I'm very happy to see this work! The era of rendering vector graphics in GPU compute shaders is upon us, and I have no doubt it we'll start seeing these in production soon, as there's just such a performance advantage over CPU rendering, and I believe trying to run vector 2D graphics through the GPU rasterization pipeline doesn't quite work.
This code is simpler than Vello (the new name for piet-gpu), focused on vector path rendering. It's also a strong demo of the power of WebGPU, while also having a performant software-only pipeline. I definitely encourage people to take a closer look.
> I believe trying to run vector 2D graphics through the GPU rasterization pipeline doesn't quite work.
I mean, it does work, it's just slower than using compute in most cases. I mean, people have emulated Linux in the GPU rasterization pipeline [1], so the raster pipeline is clearly Turing complete :)
That's a different kind of thing, I think. It renders using tiny-skia, so probably comparing to tiny-skia would be more appropriate? It also sounds like resvg's renderer can be swapped out, so it may be possible to have it render with Forma.
I just tried it in my own renderer (that uses tiny-skia) to compare performance, but unfortunately forma is still lacking some features to do a proper comparison (strokes, the ability to scale shapes up instead of only down (?????), rendering without clearing).
Yes, Skia uses the traditional method of tessellating path geometry on the CPU and then having the GPU handle transforming and shading it as if it were 3D geometry. Compare that with what we see here, which uses compute shaders for the whole process.
Mozilla peeps, is it conceivable that this could eventually get into firefox, or is it not the right fit in some way.
There was a recent discussion about map rendering and I commented to "just convert to SVG and let the browser render it" to which someone said that's too slow, to which I said "so improve the browsers vector rendering" rather than do a high performance renderer just for map software.
No way! It is waaaay faster now. It was unbelievably unperformant before, but I just dealt with it because it was otherwise a pretty good map app, especially using OSM and no Google spyware.
I see no slowness in OSM+ rendering on Android once the data for an area is loaded, as you pan, zoom, etc. But the pause between opening a new location and having it rendered is quite noticeable.
It was the rendering. I had read up on the related issue tickets, and the answer was that the vector rendering was both not optimized, and not cached in any way.
A while ago I wanted to make some vector-based toy games for fun. I surveyed the available options and basically couldn't find any. If an engine supports vector graphics, it wants to rasterize them ASAP. If I asked online, the general answer was, "GPUs are for rasters, it gets rasterized one way or another. So just do that."
I dunno. I'm not that bright. I don't fully understand it all. But I feel like it should be easy to say, "here's some SVG files for my toy 2D game. I expect they'll scale infinitely well when I zoom the viewport" but alas it was such a migraine with PhaserJS/PixiJs, Godot, and Unity3D.
I'm excited about any sort of project to get you vector graphics as close to the metal as possible before being rasterized (ideally upon draw to the graphics buffer)
I work on a project that builds an SVG compliant vector scene graph and allows for detailed interaction via its API. Writing client code that can plug into the rendering pipeline or just altering the existing code is also fairly easy - comparatively at least.
I hope this makes its way into web browser rendering. I've been working on a "game engine" using SVG in the browser. When I started, everything I read said don't - because performance. However, manipulating an SVG using a reactive framework (I use Vue) makes for very readable code. Our game client is meant to be a "reference" client so readability is more important than performance, which just needs to be "good enough." However, a significant boost in SVG rendering performance would be amazing.
edit: although, as I look more deeply, I may be misunderstanding and this may not be something that would benefit existing SVG browser rendering in any way...
Ahh I also went down the SVG-for-browser game. The promise of vector (resize-and-without-loss) seemed good right.
I ran into a bunch of issues especially with text, when starting to scale "objects-with-txt", had to add bunch of weird css-stuff everywhere and not it's not very cross-browser.
I'm curious how this relates to Skia (the library that handles cross-platform rendering for Chrome and Flutter). Seems like this could be an alternative backend but also could serve as faster replacement?
forma is geared towards vector-graphics heavy use cases. A very good example would be Lottie or Rive animations or games that make use of vector graphics. Another possible use case would be places where you need a very small software renderer, like an OS's early boot.
about a decade ago I wanted to get started prototyping gameplay with vector graphics and I was dismayed at the state of available libraries to do this efficiently. I'm glad things seem to be getting much better in this space!
How about 3D modeling programs, like FreeCAD? That's currently single threaded and doesn't use hardware acceleration so it could use the boost for sure.
> Line segments are transformed into pixel segments by intersecting them with the pixel grid. We developed a simple method that performs this computation in O(1) and which is run in parallel.
What's a pixel segment exactly? Just a list of pixel coordinates that intersect?
A pixel segment is a line segment that fits inside of a pixel's square box. It can start and end anywhere inside of this 1x1 square box and it has a 64bit compact representation.
Converting strokes to fills isn't that hard conceptually and it's what Pathfinder did. Most of the work is just supporting all the stroke features that SVG supports (joins, caps, dashes, etc.)
It's quite easy to get the CPU back-end running with WASM. GPU might work as well with Chrome Canary, but I haven't tested it yet. Using WebGPU should make this just as easy.
I'm interested enough to click on a demo, but I'm not _quite_ interested enough to figure out what hoops I would need to jump through to get that demo running myself.
Slightly curious why it's on the google github account, if it's not an official google project, or even endorsed by google? Surely this should live over on github.com/dragostis/forma then?
If you're a Google employee, there's a few different paths to 'legally' open sourcing stuff without violating your employment contract. The simplest and fastest one is just to assign copyright to Google, use an approved license (basically anything non-copyleft) and stick it under the google/ github org. It being there doesn't mean Google sponsored or authored it, just that a Googler worked/works on it. And the "not official Google product" text is mandatory in the README.
There are other processes that allow you to retain copyright for yourself, but they require approval process.
(I used to work at Google, and have followed this process before.)
Yeah, I suppose they could create a separate org, "Google Open Source" and put it there, but probably they'd like to reserve the right to own and then change the "not official" to "official" whenever they please.
There are many lawyers and such at Google who think about these things more intensely than you and I do. I'm sure they have looked at all angles.
EDIT: I do find it amusing to watch HN and other forums whenever something new and interesting is dumped under the /google org and people need to be convinced it's not some radical new direction Google is taking. But I've also been wrong before. I dismissed Fuchsia as a personal hobby project that grew out of control, until it grew out of control enough that it rm -r'd everything I'd been working on for 2+ years.
I'm sure the lawyers looked at all the legal angles but I don't know if they thought about the perception. But on a scale from 1 to "what were they thinking" this is pretty minor.
It’s very similar for Khronos, the github org of which contains projects that aren’t official Khronos products, but just something related and made by one of Khronos members.
Most people I think just use their personal github but join the Google org. And then you get booted from it when you quit.
Commit rights, I'm actually not clear on, but by default I think you'd lose rights. I believe there's likely a process for keeping them,, but I don't recall what it is. The one repo I contributed to that followed this process was essentially abandoned long before I left Google.
There are definitely things under the google github org that are used in production, though they are typically mirrored from Google3 in some way. But not sure what, if any, has its origins in a personal open source projects.
i work on https://github.com/google/pytype which is largely developed internally and then pushed to github every few days. the github commits are associated with the team's personal github accounts. pytype is not an "official google product" insofar as the open source version is presented as is without official google support, but it is "production code" in the sense that it is very much used extensively within google.
This code is simpler than Vello (the new name for piet-gpu), focused on vector path rendering. It's also a strong demo of the power of WebGPU, while also having a performant software-only pipeline. I definitely encourage people to take a closer look.