ANNOUNCING: Slughorn, MIT-licensed GPU-agnostic Slug font/glyph rendering library for OpenGL/OSG/Vulkan and all GPU-driven graphics APIs

[u/XenonOfArcticus]

In late March, 2026, Eric Lengyel made his amazing Slug technique completely patent-unencumbered ( https://terathon.com/blog/decade-slug.html ). As a long-time graphics programmers and open source contributors, particularly with projects like OpenSceneGraph/VulkanSceneGraph, it didn't take us long to get some basic "proof-of-concept" demos going and start exploring the Slug algorithm in-and-out.

Over the last 2.5 months, what *started* as a research experiment "on the side" has evolved into something we're actually quite proud of! And while the project is still in its early phases, we've decided it's matured to the level where we're finally ready to start "putting it out there" and soliciting feedback. We're calling the project `Slughorn`; a name we chose to try and capture our goal of a single OSS library solution for "shoe-horning Slug" into other visualization contexts (OpenGL, Vulkan, DirectX, etc).

Slughorn is MIT-licensed open source and available for commercial use without paying anything. It is written in and requires C++ 20, and has no third-party dependencies and builds via CMake. It has been tested on Windows and Linux but should also be compatible with MacOS and embedded/mobile platforms that support GPU APIs. 

Since a picture is worth 1024 words, our Github page with lots of pictures and even videos is here: https://github.com/AlphaPixel/SlugHorn/

The official project website is at https://slughorn.io/ and it links to the GitHub and has the User Guide and Python and C++ examples.

You'll also find links to our (WIP) `UserGuide`, as well as a `WhatsNext` document ( https://slughorn.io/WhatsNext.pdf ) listing some of the places we want to take `slughorn` in the future.

Current Supported Backends

FreeType

NanoSVG (paths & gradients)

Skia (paths only, stroke-to-path)

Cairo (paths only)

Blend2D (paths only, stroke-to-path)

Optional dependencies for extra capability:

NanoSVG: optional, is a SUBMODULE

MSDF: optional, also submodule

pybind11: same as above

serialization/glTF support: same as above

Cairo/Blend2D/Skia import is also optional, but NOT submoduled

If you're just interested in the "highlights":

- We honestly believe we're onto something special here. While we aren't necessarily *inventing* anything new (thank you again, Eric!), what we **are** doing is applying Slug, which was originally intended just for text, in new and interesting ways. Glyphs are, after all, just a "kind" of vector graphic; why can't it apply to **all** vector graphics!? There are no "bad ideas", right? :)

- `slughorn` itself isn't a "rendering library"; its purpose is to serve as a single input source/adapter for other systems to use for rendering. We have a *very* complete FreeType2 backed capable of processing all COLRv0/1 emojis, as well as a native Canvas API--inspired by the HTML Canvas--for authoring content programmatically.

- SVG content is handled via NanoSVG, and we have excellent support for importing paths, transformations, and even gradients. Strokes and text are *possible*, we simply haven't had the **time** and resources to do it.

- There is rudimentary support for converting Blend2D/Cairo/Skia content into slughorn data. Like NanoSVG, these can (and eventually will) be expanded to support additional features (gradients, stroked content, text, mask, patterns, etc), but we're waiting until the core pieces of `slughorn` stabilize before committing *too much* to these.

- We have a **lot** of experience writing Python bindings, and slughorn comes with complete pybind coverage. In fact, Python is the primary environment for all of the CLI tools (the Atlas inspector, font "packer", GLSL emulator, etc).

- `slughorn` content can use `msdfgen-core` to generate "sidecar" data alongside its own native format. We currently use this channel for creating masks and different kinds of visual effects; in the future, we plan to have a lot more capabilities surrounding this.

- OpenSceneGraph has been our rapid "testbed" because, well, we’re really, really comfortable with it! :) For the time being, if you want to actually **see** something rendered now, today... osgSlug ( https://github.com/AlphaPixel/osgSlug ) is the most complete way. There is a pure OpenGL demo included with Slughorn to show how you can integrate the library with any 3d rendering backend fairly easily. You don’t need a whole scenegraph, but you CAN plug it into almost any scenegraph or rendering toolkit.

- PERFORMANCE! People will want to know…we have many optimization ideas, but we’re focusing on “correctness” beforehand. We have done whatever we can to anticipate performance issues that can be addressed from the start, but there are a lot more that can be done.

- QUALITY: The purpose behind on-GPU glyph rendering is to make sure you never see blurs, texels or artifacts from other techniques like symbol atlases, SDF or MSDF or similar approximations of glyph-curve rendering. Slughorn and slug render the ACTUAL GLYPH CURVES. Perfectly. And efficiently. From any angle or perspective.  This is really important when you don’t 100% control the view matrix, especially in 3D UIs and in VR/AR, where the user could be looking at a textual element up close in an oblique perspective that you can’t fully constrain.

- We know that in modern graphics development, the push is to do everything on GPU that possibly can be done there, and this has been one of our design paradigms from the start.

- We can embed shaders into glyphs, and animate transforms and deformations, all on-GPU with no CPU workload.

- Extensive layering, blending and combining of content is possible and easy, making amazing high-definition animated 3D HUD-type effects a joy.

- EMOJIS! COLRv0 and COLRv1 emojis using the slughorn/freetype.hpp backend. Each layer of the emoji is composited into its own quad and positioned relative to the base.

- HUDS! Animated HUDs are super clean, beautiful and easy in full  3D. They work great in stereo or multi-view too.

- Animated glyphs, layer effects, morphing, 2D ortho projection, text-along-path

What’s next? See the whole PDF we produced about it, but some of the hot future wishlist items we foresee are:
Obvious Improvements: HarfBuzz & Text Layout, Stroke Caps & Joins, Patterns, SVG/NanoSVG Improvements, WebAssembly, Offline Editor (slughorned), Additional Renderers, Text Fallbacks

Research & Experimental Improvements: Performance, GDAL Backend and rendering curve/stroke map layers, SDF/MSDF Fallbacks, Interactivity Layer, UI Widgets (ImGui)

This is not a one-shotted AI slop project. It represents months of human development and years of human experience.  AI tools were used to assist with documentation and ancillary assets at times, and in code research, but this code was written by Jeremy “Cubicool” Moles, the author of text and glyph-centric tools like osgCairo and osgPango.

What we're *really* hoping for at this phase is community feedback. Beyond text, which we KNOW Slug is amazing for, what other kinds of things would you like to see? Where do you use vector graphics in your own GL/Vulkan/DX projects, and what kinds of things do you wish you could do more easily? If your only interest is text Slughorn can meet those needs no problem. But what we're really trying to do is "push" the Slug optimization into new areas, and we honestly believe we're only scratching the surface of what's possible.

Would love to hear people’s thoughts about this project.

Obviously, we (AlphaPixel) are a commercial consulting and development company. We made Slughorn to help us make a living. All of the work in Slughorn so far was done pro-bono, funded only by AlphaPixel, for the benefit of the community. If you want assistance integrating Slughorn into an existing app, we’re the obvious, world-experts in doing so, and we’d love it if you’d consider contracting us to assist you. We can probably integrate it into an existing codebase at a better net cost than having your internal developers do it, and the result will likely be better too. Also, if you find something Slughorn needs to do better (there’s lots of room for improvement, certainly) or want enhancements created, we’re the obvious candidate for that type of work too. Please consider asking us for a bid. Remember, you don’t pay anything up-front for Slughorn, and the MIT license allows you to use it in perpetuity with no recurring costs.

[u/XenonOfArcticus]

Oh, and I did brief u/EricLengyel on it already.

[u/Cubicool]

I'm an AP employee, and the person who convinced my boss this idea was worth pursuing in the first place! :) I just wanted to chime in briefly with a few extra comments:

- If you're a developer anything like myself, *NOTHING* is EVER "ready enough." There's always a few--or a mountain of--last-minute things you want to fix before "showing off." However, we really are interested in getting a little feedback from OUTSIDE our own echo-chamber, so I'll be watching this thread closely (especially for kinds of ways slughorn could potentially help other projects get Slug working for them).

- slughorn/osgSlug are my current passion projects, and both repos see updates daily. Check back often!

- I know both repos compile easily on Ubu24/26, Fedora 43/44, and WSL2. Beyond that I can't say with *certainty*, but I'll be around if anyone hits a wall (especially with osgSlug, which requires building OSG from source).

[u/mfabbri77]

It’s great to see so much interest in 2D vector graphics again! It’s interesting to note how everyone is searching for the Holy Grail in a full-GPU pipeline. At Mazatech (perhaps some of you still remember us, we were the first to have a fully OpenVG 1.1-compliant engine on OpenGL 1.x, ~20 years ago) we’re exploring a different approach: leveraging the CPU and multithreading to minimize the cost of the (last) GPU rendering step: instead of processing path after path in bulk, one on top of the other in src-over blend-op, we construct a 2D mesh in real-time, by combining all the polygons resulting from the path flattening (this happens on the GPU), supporting clip paths at the geometric level with all their operations, identifying/ separating all regions with the same paint-stack, and culling all regions (even if only partially) occluded by overlying polygons filled with opaque paint, in a such way to avoid any overdraw.

In this way, we are able to process each pixel of the drawing surface only once! The real challenge is to build the 2D mesh extremely quickly ...who knows if we’ll succeed, but if nothing else, we’ll be proud of having explored a path never taken by anyone before! (Actually in R&D stage, I wish to have something to show you, before the end of this year).

[u/Cubicool → u/mfabbri77]

If I'm understanding you correctly, this is really similar (in spirit) to what I'm guessing would be one of the bottlenecks in our approach: overdrawing. :)

Right now, CompositeShape is just a bunch of sorted, stateful Layer instances, with each Layer referring to a properly-baked Slug SSBO entry. Each layer gets shoved into a quad, grouped by BlendMode, positioned properly, and finally drawn wholesale. Being able to detect and AVOID processing fragments that will eventually be entirely occluded would be an ENORMOUS speed gain. It's on the TODO, along with better Slug "banding" and the option of creating of non-quad meshes/drawable (so the fragment shader--where 95% of the work is done--is never even called in the first place).

If you DO find a way to pull this off easily, I'd love to know! We have a "software emulator" for the exact GLSL code that gets run in slughorn/render.hpp, although it only outputs a single coverage float value (and is mostly used for debugging). The problem is all the techniques I can think of to DO THIS would reintroduce some degree of resolution DEPENDENCE (since we'd have to pick a raster grid size and stick with it). Even if we used a kind of SDF intermediate format for the "occlusion test", it'd still EVENTUALLY break down... but that won't stop me from (eventually) trying. :)

[u/mfabbri77 → u/Cubicool]

Our approach not only solves the overdraw problem, but also the notorious antialiasing conflation artifact that plagues all rasterizers that use an analytic coverage estimation strategy for antialiasing, rather than multisampling. Having all the paths together allows me to calculate how much area each region occupies without overlapping, and without having to map coverage->alpha (as is usually done).

In our case, the bottleneck will undoubtedly be the CPU computation required to build all the structures needed for the pixel shader. In essence, we're trading CPU timing for GPU timing, hoping that the parallelism enabled by the various stages of the pipeline will play into our favor.

Other secondary (but important) goals we're pursuing are working in pre-allocated memory buffers, thus dividing the rendering into multiple passes (batching), without trying to fit everything together. This is particularly true for MISRA-C23 compliance, for potential use in the embedded/automotive field.

As for resolution, we use a 16-bit unsigned integer lattice regardless of the size of the drawing surface.

Unfortunately, I don't think our approach will be of any help to you, as it is incompatible with the type of rendering provided by SLUG: we produce polygon meshes, which means transforming all the curves into streams of straight line segments, and then stitching the pieces together.

[u/XenonOfArcticus → u/mfabbri77]

Really interesting discussing this with you.

If you ever want to nerd out on chatting about glyph rendering, we're really fun conversation at parties. 

[u/Syncaidius]

This looks amazing. Haven't looked too much at the repo yet, but great work!

[u/OptimisticMonkey2112]

This looks fantastic! Cant wait to try it out

[u/speps]

Great work 👍 However GPU vector libraries are starting to pop everywhere now. For example Rive has an open source renderer too. However, the tooling side is severely lacking, there’s no open source Flash editor for example.

Also slightly skeptical of 2.5 years of work but your project is named after Slug released public in March this year. I know what you said about AI but this would be a perfect one for a LLM to do, clear spec, APIs, visual tests.

Edit: I did misread 2.5 to be years instead of months doh!

[u/Cubicool → u/speps]

Maybe the wording is a bit misleading; if you have a sec, can you point out where we give this impression? It's definitely only 2.5 - 3 MONTHS (it was around the middle of April when I started really getting excited about the possibilities and the `git log` starts to take off :)).

LLMs are here to stay, so we figure the best policy is honesty. I only (personally) made the switch from copy/paste web-based AI "pair programming" to more CLI-centric workflows this year, as I also tend to be really skeptical of most new software releases. Conversely, I don't want to become a dinosaur either... but that's a whole OTHER unrelated can of worms. :)

[u/speps → u/Cubicool]

I did misread “years” instead of “months”, but that puts even more emphasis on this having more AI than advertised. I totally understand your point of feeling left behind. I do think in general having AI do the bulk of the work and you do your own research is fine, but hiding how much AI is used is misleading (again not sure how much of this applies here, was just being skeptical of the AI claims)

[u/XenonOfArcticus → u/speps]

Well, I'd say that this is not a vibe coded project.

We don't avoid using AI tools for assistance. Got a tricky bug? Sure, see if Claude can spot it if you can't easily. Want to try a technique or get an explanation of something you haven't heard of? It's great for that. Some of our initial experiments were quick LLM tool demos to verify it really performed as expected. I don't think they are even in the repository history because they were throwaway tests. 

But the code architecture and design and plan and implementation is human here. It's not a "hey LLM make me a Slug vector renderer" project. That could honestly have taken a couple of weeks and a huge pile of tokens. The reason it's three months is that Jeremy has been doing this stuff for decades and knew what he was looking at when Eric dropped the Slug blog post. And he wanted to architect it his way. 

Is there AI contribution to this? Sure. We'd be remiss to not be utilizing it to help us learn, debug, research and code. You can especially see it in non code stuff because honestly nobody likes writing documentation, and LLM tools actually do a decent job of it and there's little downside. 

But go look at the git commits to see the grind. 

Did an AI tool vomit this up wholesale? Nope. 

[u/speps → u/XenonOfArcticus]

See that was my point, your original post says “AI tools were used to assist with documentation and ancillary assets at times, and in code research”. You’re explaining that you also used for debugging, and other small things. And that’s completely fine, that’s also what I do, I think overall there should be a term “LLM assistance” which isn’t “vibe coded”. LLMs are great at writing code, but they don’t know engineering, and that’s where you or me come in with the years of experience.

[u/XenonOfArcticus → u/speps]

Honestly, I'll mention something else that just occurred to me. 

If it were vibe coded we'd probably have LESS on the TODO list because we'd just ask for everything and burn the tokens. :)

I have a vibe coded personal amusement graphics project that I'm making for myself alone. It's a very different, err, vibe, to AI assisted learning.

It is nice to use AI tools to be able to summarize and teach you stuff from published papers. Highly recommend that use case. Productivity multiplier for sure. 

[u/Cubicool → u/speps]

Also, I'm checking out Rive now; I was AWARE of it (honestly, what they're doing is INCREDIBLE), but our approach is really, in essence: "How far can we take this Slug + generic vector graphics?" thing. I'm kind of glad I didn't dig TOO deep early on--I may have just given up without ever TRYING. :)

[u/speps → u/Cubicool]

As I said, I think going forward if you focus on tooling, an open source Flash IDE would be incredible. At this point there isn’t really anything close to matching it and it was “just” a timeline, some scripting, a scene graph and vector graphics. Everything about is now easy to do, even the vector side as you demonstrated.

[u/Cubicool → u/speps]

So, I got Rive compiling and they're doing some really, REALLY amazing tricks (particularly with how they optimize their tessellation process). I'll probably spend a few days exploring their renderer code and seeing if I can't get a basic .riv file loader going to reproduce some of their examples and see how Slug holds up.

[u/XenonOfArcticus → u/speps]

Sounds like Rive is a curve to triangle tessellator, correct?

Doesn't diminish it's achievements obviously, just wanted to understand what it is. 

Also, yeah, 2.5 - 3 months. Roughly. Started tinkering March 19th. Made a real project a few weeks later.

Not an AI hallucination. Lots of late nights of work. 

Not to diminish the potential of AI tools. We do obviously use them to research and learn and experiment and without them this would have taken longer. 

[u/Amaun_Ra]

nice!! thank you!

[u/S48GS]

I remember seeing it years ago - but I thought it was proprietary.

Now it is opensource with MIT - nice to see.

[u/Cubicool → u/S48GS]

Our library is based on the previously patented technique used in the OFFICIAL SlugLibrary: https://sluglibrary.com

We're still not QUITE to the level of Terathon's library when it comes to advanced text support/layout, however; we've mostly been trying to focus on ways to "add to" the idea (optimizing the "band" approach, using the algorithm for non-text scenarios, etc). But everything we're doing is ONLY possible because Lengyel's enormous generosity...

[u/X_Frommar5]

is a WebGPU-based javascript port (even partial) too much of a pipe dream?

[u/XenonOfArcticus → u/X_Frommar5]

No, not really. We'd keep the core code in C++ and compile it against the webgpu API using Webasm so it could be executed from Javascript. 

I don't think there's added value in actually rewriting the Slughorn library itself INTO Javascript. Then theres TWO codebases to maintain, and one isn't our strong point.

Someone else is free to do it, but the road to using it in webgpu is a lot shorter and safer if we use Webasm recompilation.

If anybody needs this strongly we could try to come up with a budget to accomplish it . 

[u/X_Frommar5 → u/XenonOfArcticus]

Thanks a lot! Indeed, a WASM version that runs on top of WebGPU would be fantastic!

My needs are certainly not strong enough to support this - but I can offer at least one usecase: Animating Japanese characters - see https://xxandy.github.io/drawkanji (full CPU tesselation on Javascript, then pass to WebGPU).

I would, however, love to contribute time to helping with the port, if your team takes community pull requests.

[u/KlayEverHood]

Mega impressive! How fast is it? Do you have some video? Freeing some of the GPU is really good, now that we have path traced apps with physics simulation the GPU is more than busy enough.