https://github.com/user-attachments/assets/5ca6563e-a7d3-44df-9800-beb8716efcad

slughorn

🔨 What We're Working On   _{Last updated: September 1st, 2026}

	Feature	Status
🎨	Add support for improved "decal" style rendering
🎨	CI/CD Python package builds/publishing
🧰	Reduce texture memory usage
🧰	Key mask/namespace support
🧰	Add support for simple Miters/Caps
🧰	Remove the expand parameter as CPU-side "hack"
🧰	MSDF and procedurally-based CompositeShape masking
🔧	Full Porter-Duff compositing and blend mode support
🔧	Improved Blend2D and NanoSVG feature support

Related Projects

• osgSlug
• osgx
• OpenSceneGraph.py

slughorn is modern C++20 library implementing the recent OSS release of the "Slug" GPU vector graphics rendering technique by Eric Lengyel. It makes no assumptions about what graphics environment is being used (OpenGL, Vulkan, WebGL, WebGPU, DirectX, etc) and instead focuses only on simplifying the process of creating/ingesting vector data from various backends--or, alternatively, by using an HTML "Canvas-like" API directly in code--so it can be directly uploaded to the GPU as easily as possible. A backend is simply an implementation that produces Bezier curves for slughorn to process to facilitate drawing. Further code outside of slughorn draws the curves with a graphics API like OpenGL, Vulkan, WebGL, WebGPU, Metal, DirectX or similar, potentially using toolkits like but not limited to OSG / OpenSceneGraph or VSG / VulkanSceneGraph. Companion projects ( https://github.com/AlphaPixel/osgSlug ) assist with this integration.

Furthermore, slughorn provides tools for traditional "offline asset" processing (primarily in Python), as well as a glTF-compatible JSON file format.

Architecture

slughorn operates in two complementary modes. As a first-class authoring tool, it provides a Canvas-like API for building vector content directly in code — shapes, text, gradients, and composited layers — all flowing into the GPU atlas without any intermediate library. As an adapter, it bridges existing vector ecosystems (Cairo, Skia, Blend2D, NanoSVG, FreeType) into that same GPU-ready pipeline, letting you keep your current authoring workflow while gaining resolution-independent, perspective-correct GPU rendering. Most GPU vector renderers want to own the authoring; slughorn is being developed to support bringing your own.

The divison is basically: slughorn is the "unified source of truth", providing data and hints/constraints about how that data is used; your frontend decides what do with it.

Current Supported Backends

• FreeType
• NanoSVG (paths & gradients)
• Skia (paths only, stroke-to-path)
• Cairo (paths only)
• Blend2D (paths only, stroke-to-path)

In addition to the above backends, slughorn provides a "native" API for authoring vector graphics inspired by the standard HTML Canvas element.

Adding support for other backends is generally as easy as using a single helper class: slughorn::CurveDecomposer. If your vector data can be reduced into simple quadratic Bezier curves, slughorn can make it render.

Supporting most of the missing Skia/Cairo/Blend2D features (gradients, patterns, text, clipping/masking) is entirely possible, it just requires time/effort. As slughorn continues to evolve, so will those backends.

Demos

Note on demos: All video demonstrations above are captured from osgSlug, the intentionally separate OpenSceneGraph-based testbed developed alongside slughorn. slughorn itself has no graphics dependencies, and osgSlug exists to prove the integration story and serve as a reference implementation for other graphics backends.

Skia

Compilation

cd ~/dev/skia
rm -rf out/Release
bin/gn gen out/Release
ninja -C out/Release skia

Why Slug Instead of Skia's GPU Backend?

What Skia Actually Does on the GPU

Skia has two GPU backends: Ganesh (the older one, OpenGL/Vulkan/Metal) and Graphite (the newer one, designed for modern explicit APIs). Both work by:

1. Tessellating paths into triangles on the CPU (or via compute shaders)
2. Uploading those triangles to the GPU
3. Rendering with relatively simple shaders

The key word is tessellation; Skia converts your curves into triangle meshes. This means:

• Quality is resolution-dependent; you have to choose a tessellation tolerance, and if you zoom in far enough you'll see faceting
• Every time the path transforms (scale, rotation, perspective), you either re-tessellate or accept quality loss
• Perspective projection of curves is fundamentally broken with tessellation; a cubic Bezier projected through a perspective matrix is no longer a cubic Bezier

What Slug Does Differently

Slug evaluates the exact curve equations per-fragment in the shader. This means:

• Quality is resolution-independent; zoom in infinitely, edges stay perfect
• Transforms are free; the vertex shader handles them, the fragment shader doesn't care
• Perspective is correct; because you're evaluating the curve at each pixel, not approximating it with triangles
• No CPU tessellation step; the atlas is built once and never rebuilt regardless of transform

Comparison

OSG Integration Specifically

Getting Skia's GPU backend working inside OSG would be genuinely painful:

• Skia wants to own the OpenGL context; it manages its own state, its own FBOs, its own texture atlases. OSG also wants to own the context. Getting them to share without stomping each other's state is a known headache.
• Skia's GPU API is not designed to be embedded; it's designed to be the renderer, not a component of one.
• You'd essentially be running two renderers side by side and compositing, which introduces synchronization, blending, and depth buffer problems.

Slug, on the other hand, is just a shader and two textures; it slots into OSG's existing pipeline as naturally as any other osg::Program.

The Real Answer to "Are You Reinventing It?"

For 2D UI / document rendering at fixed resolution; Skia is better. It's battle-hardened, handles edge cases you haven't thought of yet, and the tessellation quality is fine for screen-resolution work.

For 3D scene graph rendering with arbitrary transforms and perspective, Slug is genuinely superior. The moment you want text or shapes on a billboard, a HUD, a curved surface, or viewed through a perspective camera, Skia's approach starts showing cracks and Slug's approach shines.

Slug is solving a different problem that Skia deliberately doesn't address.

AI Disclosure Declaration

AI tools such as Codex and Claude have been used for research and some code development. However, this is not a "fire and forget" AI project. It was carefully designed, planned, architected and implemented by a live human (cubicool@gmail.com). AI tools were also used for producing documentation and ancillary data products to accelerate development.

Sponsorship

This project grew out of internal research and experimentation at AlphaPixel (AlphaPixelDev.com) based on the 2026 release of the Slug algorithm (https://terathon.com/blog/decade-slug.html) patent by its author, Eric Lengyel, for whom the whole Slug-using community is extremely grateful.

If you are interested in assistance with Slug, slughorn, OpenGL, OpenSceneGraph, Vulkan, VulkanSceneGraph, AR, VR, xR, 3d mapping, or almost any other performance-centric computing, please contact AlphaPixel. We are mercenary programmers who can provide rapid assistance to any challenge, and our motto is "We Solve Your Difficult Problems."