When the Slug patent was released to the public domain, I put together[1] Snail[2], a Slug implementation in Zig.
One thing I found was that it was tough to get small text to look good with some fonts. TrueType fonts often have bytecode that tweaks curve points to better fit the pixel grid at a particular size. Part of the pitch for Slug is that it doesn't require per-size glyph prep, so Slug text is just unhinted.
As monitors have gotten denser, the major font renderers have moved away from bytecode hinting, either toward auto-hinting (ignore the bytecode, look at the outline, and decide what to do) or toward no hinting at all.
Snail has GPU auto-hinting that tries to replicate a lot of that, so I could have hinted text without per-size prep. It precomputes knots at various glyph features, and the shader then moves the knots to stretch/squeeze parts of the glyph. It's not perfect (especially for serif fonts!), benefits from per-font tuning, and focuses on Latin glyphs (pretty much always draws CJK glyphs unhinted because they're too complex for the current shaders to handle). Also, cases where you want hinting and wouldn't be better served by just scissoring prepared bitmaps aren't all that common. It also includes a TrueType VM, for cases where the per-size cost is acceptable (DejaVu Mono looks decent with the auto-hinter, but it has phenomenal hinting bytecode).
It was a lot of fun to put together, I learned a lot, and as far as I know the auto-hinter is unique among Slug implementations. Slug is a very cool algorithm.
[1] through high-effort delegation to Claude
[2] https://github.com/psyclyx/snail - includes some diagrams (made with Snail!) that explain most of the prep/rendering of a glyph with Slug
> One thing I found was that it was tough to get small text to look good with some fonts.
Same here. For scaling from medium to large fonts the MSDFs were good. However at smaller "normal" font sizes they just didn't tend to look good even with larger MSDF sizes.
Plus for font rendering the GPU overhead was too large to be worthwhile for normal GUI apps. Font atlas'es are pretty small, and most fonts for GUIs are statically sized.
However I did find MSDF are fantastic for rendering complex SVG paths with lots of benefits [1]! You can use a 64x64 SVG star and scale it up fullscreen with reasonable loss in quality [2] (or use 128x128 for almost lossless images).
I use them as the core of my GUI library to render complex SVG paths for icons and such and compose individual paths on the GPU.
You can use them to implement fair chunks of Lottie animation as well [3]. Though I never got enough into the Lottie work to go beyond basic demos, but you could easily scale MSDFs, add shadows, feathering, outlines, etc at 100+ FPS.
Frankly, I don't bother with hinting at all for my renderer (based off libschrift, which also does no hinting) for that reason. It probably still looks marginally better. But the complexity just doesn't feel worth it any more.
I once implemented SDF text rendering. To me, the thing I liked the most about this technique it how easy it is to add effects on top. With a few lines of shader code, I had outlines and softening of the edges (antialiasing). I didn't try the MSDF variant, as I didn't mind corners not being sharp when scaled up, so I don't know if these effects break on MSDF.
Slug doesn't seem to support any of these, it is just "for a given point, am I in or am I out?", but it doesn't tell you by how much, which is great on really high resolution displays and large sizes, but you would lose the ability to do the kind of effects you can do with SDFs, and have to deal with antialiasing separately.
> Slug doesn't seem to support any of these, it is just "for a given point, am I in or am I out?", but it doesn't tell you by how much
It does give you an anti-aliased value between 0 and 1 that estimates how much of a pixel is being covered.
But this is a linear estimate based on horizontal and vertical distance to the Bezier curve. It does not look correct at long distances, which is why you shouldn't use it for outlines, drop shadows or the other cool things you can do with (M)SDF. A single pixel outline works fine but is not really legible with modern display resolutions (very thin lines).
For finding the minimum distance between a quadratic Bezier curve and a point would require solving a 3rd degree polynomial, where Slug's algorithm gets away with solving a quadratic equation per pixel. This is makes a big performance difference.
Having a technique that optimizes solely for whole pixels seems relatively reasonable, given current hardware PPIs. Systems that want to handle grayscale could use a different technique for that.
That said, there are interesting effects other than grayscale antialiasing, and I wonder how well slug could handle things like outlines (useful for subtitles over video, to make them readable on any background).
Not especially, unless you're running something like a high-refresh-rate gaming monitor that's still 1080p or less.
On most current phones, laptops, and monitors, I would expect the difference between grayscale antialiasing and monochrome rendering to be hard to notice.
> unless you're running something like a high-refresh-rate gaming monitor that's still 1080p or less.
Or HMDs. Upcoming high-resolution PICO Space Pro is said to be ~45 pixels/degree max. Versus ~50 ppd for a 1080p laptop. Formerly known as Project Swan, its September global release announcement was postponed until... unclear.
I wouldn’t. I’d be willing to bet 1080p is still the most popular desktop resolution for the average corporate office PC, and that the most popular displays for 4K gaming are UHD TVs large enough to see pixels at close but reasonable viewing distances.
I've also been working on a GPU curve renderer, Windfoil, based on a formulation that Fable 5 originally proposed to me during a directed search [1]. It is similar in some ways to Slug, not always as fast, but uses less shader storage (single band instead of two) and produces higher quality anti-aliasing i.e. closer to a box-filtered ground truth.
It may be of interest to some game/graphics devs here...
interesting. how does the AA work in your algorithm?
the reason slug has two bands is precisely because of its anti-aliasing. you having only one implies you do the AA differently, or are less efficient with searches off the main direction.
for readers: the slug shader traces two rays, one horizontally, and one vertically, to find out if a pixel is inside a glyph or outside. one would be enough for pure inside outside, but for anti-aliasing purposes it's also helpful to know how far away you are from the closest edge. but if you have a horizontal ray running parallel to a horizontal glyph edge (not uncommon), the ray glyph intersection will return no value at all.
so slug traces two rays and blends between them for anti-aliasing that always works in both cases.
the bands mentioned here are just acceleration structures, basically a list of cells where each tells you which parts of a glyph are contained within it.
it's still approximate. a true ground truth would just supersample and do many point-in-glyph tests within one real pixel - at edges some of them would be inside, and some of them would be outside, giving you a smooth value to display depending on the shape of the glyph within the edge pixel.
Windfoil uses boundary integrals to average winding over a given rectangular footprint (normally one pixel, independently in a fragment shader). For many cases, like typical text glyphs, this will reproduce a box-filtered ground truth exactly, i.e. for those shapes it is not approximating AA like Slug or MSDF. But because it takes the average and then applies a fill rule after, it's not an exact in all cases (fwiw, Slug can produces similar errors with tricky self-crossing curves and such).
This article has some inaccurate information since MSDF atlas doesn't have to be baked statically, so the "CJK character means huge atlas" is not really an issue if you can async upload them to the atlas.（Async outline extraction is a bit harder for C libraries, so that's why the pipeline is mostly restricted to atlas upload).
The other thing is MSDF rendering is fairly cheap and can be done on the CPU quite easily without GPU shaders, the atlas generation/upload is the expensive part, but it's a one-time cost per character per font as the atlas is just a normal bitmap texture file, MSDF text have sharp edges at most zoom resolutions, and the small size text is better handled with simple CPU raster anyways.
I really failed to see significant benefit of using Slug over MSDF + raster fallback for small fonts, it's definitely more exact, but I'm not sure if the marginal resolution benefit is worth it over much more complicated GPU dependent rendering, so I'd really want to test it out myself when I have the time over taking the word of an obviously AI written article for it.
Yes, there is at least one downside to MSDF among a set of possible downsides (huge atlas, or dynamic rebaking, or limited glyph set), and the article is written as though they all apply, which is a bit misleading. Slug is cool, glad it exists, but it isn't the right fit for my rendering project either.
Article author here (not the lead programmer on the Slughorn project tho).
Yes, LLMs were used to help write this article and there are tells. I can smell them too.
However, as several have picked out, it's not a one-shot LLM Leeeeroy-Jenkins writing process. I am a domain expert in these sorts of things, and the source of much of the information, concept and organization of the article.
I wrote a bunch of notes and material. I then used an LLM trained on my own styleguide from my writing to organize, expand and fill in places where it was mostly gathering info from other sources. Then I went through THAT and rewrote a bunch because it doesn't always follow directions and color within the lines. It took several days of iteration to put this together even with an LLM assisting.
So, there are parts that are entirely human. There are parts that I felt were less important for me to write personally that I let the LLM writing stand, with some edits.
It is a HUGE piece of work, and writing it all by hand would have taken more time than I could dedicate to it because I have to make a living too.
I should go back and de-LLM it some more, but legit our time is spent working on Slughorn to make it better. I welcome all suggestions for edits and errata on the article (or on Slughorn itself). Our goal isn't to trash other rendering methods. It's not a competition. The post is intending just to fairly compare all of them so people can decide what technique is best for their use, because Slug/Slughorn ISN'T the right choice always, and there's so many techniques with different tradeoffs that it can be hard to grasp where your own use-case falls and how to decide.
Also, Cubicool, the primary developer of the Slughorn code will probably chime in below to address some of the more code- and feature-centric responses.
(Finally, cheers to Eric L. for releasing the Slughorn patent that made this all possible.)
There are tells in almost every sentence but some flagrant ones: “where every technique below makes its trade”, “every size you want crisp is another atlas”, “a bitmap has no idea it is being viewed in perspective”, “the fix that carried the industry for a decade”, “it lies about corners”, “built for artwork that moves”, “what separates them is technique, not resolution”, “text is where Slug earned its name”.
These are Claudisms, cloying mannered prose cliches that often anthropomorphize concepts, with an uncanny and annoying smugness.
It seemed to get more LLM-y the further down, the first thing I noticed was when it said "genuinely" in a way that didn't fit the tone. Then it said "genuinely" again. Then I started paying attention and I noticed it was basically filling up every other sentence with bullshit to sound "clever". Stuff like
> reduces antialiased vector paths into unique triangle patches and rasterizes them through a massively parallel pipeline with pixel local storage
this is typical type of LLM sentence that kinda runs under the radar, sounds clever, but if you actually look at it, none of it makes sense
I won't try to convince anyone with specifics but it was definitely LLM generated. I think by someone who knows what topics they want to cover and did have something they wanted to post about. At a high level it is an infodump with almost no opinion expressed.
I learned a few things from it and have some interest in the topic. So this sort of a weird valley where I'm very annoyed by the writing but also getting something out of it. And it's more than I would have gotten out of promoting an LLM myself.
Which I know, because I have written a blog post about SDFs before, and I tried to author it with an LLM helping and the text just came out awful. I think I rewrote my entire post eventually - I am fairly confident at least that none of the LLM's words remained. I mention it because I've already read the SDF section of this blog largely, when an LLM generated mostly the same text 5 months ago.
> There is no atlas, so a hundred thousand CJK glyphs cost a font's worth of outline data, not an atlas the size of a video. Text can change every frame at no baking cost, which is exactly what you want for live data, user input, and localized content. And it all happens in a single draw with an ordinary fragment shader, no vendor extension required.
Specifically, these sentence structures:
1. ... so <blah> costs <blah>, not <blah>.
2. And <blah>, no <blah>.
3. ... fixed resolution ahead of time, which quietly ...
For me it was "head to head" table. Typical complete nonsense llm-generated comparison table. Rest of the content is still quite good tbh, generated or not
Not arguing whether this article is or isn't LLM-generated, but I've seen skewed comparison tables like that in marketing since before LLMs. Pick a bunch of qualities skewed towards the new thing being proposed, highlight all the ways the new thing wins.
As much as I'm all for human generated writing, coming across and having to read through mostly-LLM-generated writing is becoming the norm (at least for me, it's true). While I may not necessarily approve of the manner in which this was written, it was still something I wanted to know more about and I read it anyway.
It does bias me negatively towards the author, and makes me a little sad that people are choosing to not put more thought and effort into their writing, but this is a trend that is here to stay.
Making a big fuss about this hasn't gone anywhere from what I can tell, and it's unlikely that the outcome will be any different going forward.
Then don't. I'm incredibly tired of people complaining about it. This is the world now. We're going to be interfacing with these models until we take the long nap. A models personality and prose are fine things to comment and give feedback on, but this belly-aching is worse than what it said in the first place because it's not constructive at this point.
As hobby project, I wrote a font rasterizer algorithm (two algorithms actually) that produces pixel perfect anti-aliased images (like Slug) using a similar but different algorithm. Rather than using Slug's clever root classifier for Bezier curves, I subdivide Bezier curves into monotonic sections where evaluating the winding number is much simpler and can be done in parallel for a group of pixels. It works nicely on GPU with warp/wave/subgroup operations and CPU using SIMD.
At first glance, subdividing the Bezier curves sounds like a bad idea (more Beziers to rasterize) but it opens doors for some parallelism, and most Bezier curves that appear in fonts are monotonic in the first place (so the increase is very modest). This was inspired by this entertaining but not very serious video about font rasterization [0].
The first parallelism optimization is checking against the curve bounding box vs. a rectangular (in uv-space) region of pixels, and this can quickly determine if the Bezier needs to be evaluated in the first place. This can be done per GPU warp.
The second optimization works only for rectilinear transformation (no rotation, skew or perspective). Solving the quadratic equation involves a square root and a division (which alone are >30% of the computation), which can be computed for each row and column of pixels instead of for each pixel (2n instead of n^2).
Both optimizations rely on mathematical invariants of monotonicity, ie. the derivative of the Bezier curve must be non-zero. All Bezier curves can be robustly subdivided into monotonic sections using de Casteljau's algorithm.
My simple benchmarks compare favorably to Slug on the GPU and to "fast" rasterization algorithms on the CPU (which is an order of magnitude faster than "fancy" rasterization algorithms with hinting etc).
Unfortunately there are so many hobby projects and so little time. All I have is messy shaders that draw individual characters and a few benchmarks to see how quickly (and something similar for the CPU). Going from there to a complete text rendering system would be a lot of work. Writing a more detailed article with illustrative code examples is something I'd want to do but haven't gotten around to.
If you want to offer words of encouragement or geek out about rasterization algorithms, I welcome any input.
It works great except it can have z-fighting issues, especially near t-junctions.
I'm wondering if there's a way to calculate scan lines along 2 or more axes, then choose the ones with the least uncertainty.
A similar issue happens with convex hull algorithms. If we wrap along the x axis, we might get a different triangle mesh than if we wrap along the y or z axis, because vertices may be coplanar along an axis. I've considered wrapping along all 3 axes, then choosing the mesh that matches in the most axes.
Is there a general solution for this? Some point clouds have sets of vertices that are coplanar regardless of which axis we use. I suspect that the number of axes needed might be proportional to the number of vertices. I wonder if we could use something like change of coordinates to wrap the mesh from the frame of reference of each vertex.
If we had that technique, we could apply it to Slug and render glyphs having minimal error, regardless of how they're transformed, if we're willing to sacrifice some performance.
There's quite a bit of helper code plus stb_truetype.h and stb_ds.h under the hood to parse TTF files and crunch the TTF curve data into the runtime format expected by the Slug shader (this stuff should better go into an offline asset pipeline tool):
...the list of external dependencies is a bit scary for a small self-contained sample though (Harfbuzz, SheenBidi, libunibreak, etc...), but that basically shows that proper international text rendering is really damn hard, even when trying to simplify the code as much as possible.
... or why it's best to just use the OS libraries to render to textures if you only need an OSD :P
Question though, you implemented the slug system? The article mentions root eligibility but doesn't expand on it, what's the point of it because slug doesn't seem too "magical" for only doing winding counts?
“What makes glyphs hard” Another reason is hinting. Traditional text renderers like FreeType are aware of the pixel grid and they adjust the curves slightly, snapping them to that grid. For all methods in the article quite hard to do on GPUs.
“Chinese, Japanese, and Korean have tens of thousands of glyphs, and baking all of them at several sizes is a memory disaster” One possible solution is dynamic atlas built on CPU for visible glyphs only.
“The distance-field panels notch, where interpolating between stored samples no longer matches the true curve” Can’t it be fixed in the shader, using screen-space derivatives of the SDF? I think in theory, SDF value for pixel center combined with screen-space gradient vector of that number delivers enough data to compute partial coverage for the pixels on the edge.
> "In 2017 Eric Lengyel published an algorithm, called Slug, that stopped dodging. It renders glyphs directly from their outlines in the fragment shader, with no texture atlas and no per-frame tessellation. Lengyel patented it in 2019, and on March 17, 2026 he dedicated that patent to the public domain."
It's nice that he gave the patent to public domain, but this is not how patents are supposed to work. You can't patent something two years after it was already published.
I'm guessing he actually filed for a patent before publishing, and the article should read: "Lengyel was granted a patent for it in 2019"
It's an AI-written article, so maybe it's not reasonable to expect it to be consistent on this level...
* The provisional patent application for the Slug algorithm was filed on March 27, 2017, and this is incorporated into the final patent at the beginning of the Description section. A provisional patent establishes a priority date for everything it discloses (which was the whole algorithm), and it gives the inventor one year to complete the application process.
* The JCGT paper was published a few months later on June 14, 2017, after the priority date.
* The final patent application was submitted on February 1, 2018, before the one-year deadline.
* The patent was granted about 1.5 years later by the USPTO on August 6, 2019.
You need to file before publishing to establish the priority date.
A sibling comment notes that he indeed filed a provisional patent in 2017 before going public. That’s the part that the article muddled. 2019 was when the patent was granted, not filed.
I'm the author of slughorn/osgSlug, and was surprised to find this thread. The article my boss put out a few days ago focused mostly on the "text-centric" aspects of Slug (which is what it was originally created for, afterall), but slughorn has grown into WAY more than that now. :) Glyphs are, afterall, "just shapes", and the whole experiment started with my asking: "why can't it just do ALL VECTOR GRAPHICS!?" And so ... yeah. Here we are.
We're still nowhere near the levels of libraries like Noesis or Rive (which are fundamentally different approaches to the same idea), but hey--maybe one day. There's already an impressively large stack of stuff I've been able to pull of with just some clever shader tricks, and I'm coming up with more things I want to try every day.
Right now I'm working on adding completely GPU-driven "path stroking" to slughorn/osgSlug (which uses SSBO to store/update a `slughorn::Path` and then does some `gl_InstanceID` tricks to dynamically "emit" the necessary geometric bounds Slug needs to do its analytical fill/antialiasing), and after that I'll go back to finishing the full Porter-Duff compositing stack.
There are also a handful of UIs from games I want to try "cloning" (Deadspace's diegetic style, the radio scanner from the Arkham games, etc). I also keep this HUGE directory of UIs I see in shows/movies; every time I see some mocked-up thing and think to myself, "I wonder how they did that?", I usually snap a screenshot to poke at later.
Here are some "just for fun" screenshots of interesting stuff I haven't put up on Github yet:
There's a whole slew of cool changes I haven't fully updated the repo with; there just aren't enough hours in the day, and we still gotta pay bills. Anyway, I'll check back later if anyone has any questions/ideas/things they'd like to see... that kinda feedback dictates what I focus on next. :)
The project I'm most known for is basically an MSDF shader with a bloom pass. It serves my needs 100%, though if I expand to support arbitrary text, I may reach for Slug.
The one issue with MSDF I want to raise is, it seems everybody uses the same msdfgen texture creation program from Viktor Chlumský's master's thesis 11 years ago. I wish there were other implementations. Who ever heard of a graphics technique that was only ever programmed once, and then used everywhere without substantial iteration? We need to de-XKCD-2347 MSDFs for everyone's sake, including and especially Chlumský.
I haven't heard of Chlumský or MSDF before, but I think a lot of people have been aware of the technique before he published his paper, thanks to Valve's TF2 text rendering paper:
The pdf details only simple SDF, but in the closing paragraphs, it mentions the weakness of the technique and mentions how it can be solved with multiple SDFs, but the exact technique wasn't showcased.
Which led to people trying to reverse engineering it, and making their implementation, for years (it's Valve after all). Including me. Not sure if what I came up with was exactly MSDF, but certainly there are a lot of implementations out there.
I'd say what you and the others did was research, not implementation. Your results were solutions to the same problem, not variations of the same recipe. What you did is important but separate from what's concerned me.
A recipe of Chlumský's— the msdfgen utility— is widely used, but only has one producer. I'm just saying that that's a liability. Like, imagine if HarfBuzz was the only text shaper, and was maintained by one person.
Interesting read. Text rendering techniques have always fascinated me.
I'm a bit confused because at some points it seems like the author is conflating "tessellation" and "Rive". Are they the same thing? As an uneducated reader, my understanding would be that Rive is an implementation of a renderer using the tessellation approach. But surely a generic tessellation approach could support perfect arbitrary transformations even if Rive doesn't?
Maybe there's something I'm missing.
Also, a nitpick: in the "head to head" section, the author highlights Slug's better performance in green for the entries that it wins (or ties). For the sake of fairness, shouldn't we highlight the winners in every category? Surely Rive's "low" memory usage beats Slug's "moderate"?
I do MSDF as well and since I'm not doing a huge-ass text editor (and even then) it works and it's great. One thing to consider is that with any solution that does things directly from vector outlines means you also then have to distribute proper font outlines and you might not have a license to do that. With MSDF and similar atlas-like solutions, you pre-render a font and distribute that rendered image instead of an actual font.
Which you also might not have the license to do. I once licensed a Monotype typeface that prohibited its use in anything editable, including fillable PDF forms.
Is there a runtime comparison of the shaders needed? Seems like you might have to do a lot of texture sampling if you have to walk the ray through the data but maybe there's a trick?
MSDF is pretty much just the target texel in question plus the surrounding samples in a way the GPU can do entirely upfront before the math starts. (M)SDF glyphs also play nicely with mip mapping and I would think this Slug algorithm needs uncompressed data. Maybe that doesn't matter because you just don't scale the data ever?
Slug doesn't use "bitmap" font data but more like parameter lookup tables in storage buffers, pre-processed from TTF files. The lookup data can of course also live in textures (so that it works in WebGL), but using those textures as "poor-man's storage buffers", e.g. fetching the data directly without filtering.
The pixel shader is indeed quite complex compared to SDF:
I knew the second Eric posted about releasing Slug to the public domain we'd get 100s of "OpenSlug" slopped-up. Will be interesting to see which implementation will win or if Slug will keep being a thing.
Tbf, the Github repo doesn't look particularly 'sloppy' to me, more like some mild AI assistance. There's several months of fairly regular looking git history, a couple of commits with an LLM disclaimer for python bindings, and two llm-context files.
Yeah, I (author) regularly use AI (anyone who doesn't is ... well, they're not seeing the same reality I am, anyways :)), but I don't just "turn it loose." It reviews my initial passes, catches stupid mistakes I make, and often has good advice about "Hey, don't overengineer this", although I _do_ have to regularly reign it in from other complete nonsense (which kind of makes me happy, because it means, you know, I still have a job). For slughorn, it mostly did some of the C++ tests, almost all of the pytest coverage, the pybind docstrings, and the GLFW example (since I do 99% of my own testing with OSG until I finish there and move on to Vulkan).
Slughorn is coded by hard-working humans. Sure, we use LLM tools for some investigation and development, but this is not an AI slop project. It's been in the works steadily since not long after Eric announced the patent release, grinding through improvements with every hour of the day we can dedicate to it.
Every important line of code here was written, tested and is understood by Cubicool, the lead programmer (there are some LLM-generated ancillary parts of the codebase, and I think git shows those).
I must apologize, this really came across as an accusation. I meant to say that, upon his announcement, I imagined there would be many 1-weekend slop clones. I have not looked at slughorn, but I really think this is cool, and I appreciate competent people working on cool problems. I'll keep an eye on this! Will be more careful with how I express myself, sorry! :)
Hey, all the power to you. It doesn't really matter how AI was used, cause I can't tolerate its language! That's why I said I skipped the article instead of accusing it of being bad or whatever. It's a perfectly fine article, just not for me.
Slug mentioned!
When the Slug patent was released to the public domain, I put together[1] Snail[2], a Slug implementation in Zig.
One thing I found was that it was tough to get small text to look good with some fonts. TrueType fonts often have bytecode that tweaks curve points to better fit the pixel grid at a particular size. Part of the pitch for Slug is that it doesn't require per-size glyph prep, so Slug text is just unhinted.
As monitors have gotten denser, the major font renderers have moved away from bytecode hinting, either toward auto-hinting (ignore the bytecode, look at the outline, and decide what to do) or toward no hinting at all.
Snail has GPU auto-hinting that tries to replicate a lot of that, so I could have hinted text without per-size prep. It precomputes knots at various glyph features, and the shader then moves the knots to stretch/squeeze parts of the glyph. It's not perfect (especially for serif fonts!), benefits from per-font tuning, and focuses on Latin glyphs (pretty much always draws CJK glyphs unhinted because they're too complex for the current shaders to handle). Also, cases where you want hinting and wouldn't be better served by just scissoring prepared bitmaps aren't all that common. It also includes a TrueType VM, for cases where the per-size cost is acceptable (DejaVu Mono looks decent with the auto-hinter, but it has phenomenal hinting bytecode).
It was a lot of fun to put together, I learned a lot, and as far as I know the auto-hinter is unique among Slug implementations. Slug is a very cool algorithm.
[1] through high-effort delegation to Claude [2] https://github.com/psyclyx/snail - includes some diagrams (made with Snail!) that explain most of the prep/rendering of a glyph with Slug
> One thing I found was that it was tough to get small text to look good with some fonts.
Same here. For scaling from medium to large fonts the MSDFs were good. However at smaller "normal" font sizes they just didn't tend to look good even with larger MSDF sizes.
Plus for font rendering the GPU overhead was too large to be worthwhile for normal GUI apps. Font atlas'es are pretty small, and most fonts for GUIs are statically sized.
However I did find MSDF are fantastic for rendering complex SVG paths with lots of benefits [1]! You can use a 64x64 SVG star and scale it up fullscreen with reasonable loss in quality [2] (or use 128x128 for almost lossless images).
I use them as the core of my GUI library to render complex SVG paths for icons and such and compose individual paths on the GPU.
You can use them to implement fair chunks of Lottie animation as well [3]. Though I never got enough into the Lottie work to go beyond basic demos, but you could easily scale MSDFs, add shadows, feathering, outlines, etc at 100+ FPS.
1: https://forum.nim-lang.org/t/14062#85314
2: https://github.com/elcritch/figdraw#msdf-bitmap-based-sdf-re...
3: https://github.com/elcritch/lotty
> As monitors have gotten denser
Frankly, I don't bother with hinting at all for my renderer (based off libschrift, which also does no hinting) for that reason. It probably still looks marginally better. But the complexity just doesn't feel worth it any more.
I once implemented SDF text rendering. To me, the thing I liked the most about this technique it how easy it is to add effects on top. With a few lines of shader code, I had outlines and softening of the edges (antialiasing). I didn't try the MSDF variant, as I didn't mind corners not being sharp when scaled up, so I don't know if these effects break on MSDF.
Slug doesn't seem to support any of these, it is just "for a given point, am I in or am I out?", but it doesn't tell you by how much, which is great on really high resolution displays and large sizes, but you would lose the ability to do the kind of effects you can do with SDFs, and have to deal with antialiasing separately.
> Slug doesn't seem to support any of these, it is just "for a given point, am I in or am I out?", but it doesn't tell you by how much
It does give you an anti-aliased value between 0 and 1 that estimates how much of a pixel is being covered.
But this is a linear estimate based on horizontal and vertical distance to the Bezier curve. It does not look correct at long distances, which is why you shouldn't use it for outlines, drop shadows or the other cool things you can do with (M)SDF. A single pixel outline works fine but is not really legible with modern display resolutions (very thin lines).
For finding the minimum distance between a quadratic Bezier curve and a point would require solving a 3rd degree polynomial, where Slug's algorithm gets away with solving a quadratic equation per pixel. This is makes a big performance difference.
Having a technique that optimizes solely for whole pixels seems relatively reasonable, given current hardware PPIs. Systems that want to handle grayscale could use a different technique for that.
That said, there are interesting effects other than grayscale antialiasing, and I wonder how well slug could handle things like outlines (useful for subtitles over video, to make them readable on any background).
I don't follow, current hardware PPIs are generally low, while whole pixels work for high?
> current hardware PPIs are generally low
Not especially, unless you're running something like a high-refresh-rate gaming monitor that's still 1080p or less.
On most current phones, laptops, and monitors, I would expect the difference between grayscale antialiasing and monochrome rendering to be hard to notice.
> unless you're running something like a high-refresh-rate gaming monitor that's still 1080p or less.
Or HMDs. Upcoming high-resolution PICO Space Pro is said to be ~45 pixels/degree max. Versus ~50 ppd for a 1080p laptop. Formerly known as Project Swan, its September global release announcement was postponed until... unclear.
I wouldn’t. I’d be willing to bet 1080p is still the most popular desktop resolution for the average corporate office PC, and that the most popular displays for 4K gaming are UHD TVs large enough to see pixels at close but reasonable viewing distances.
I've also been working on a GPU curve renderer, Windfoil, based on a formulation that Fable 5 originally proposed to me during a directed search [1]. It is similar in some ways to Slug, not always as fast, but uses less shader storage (single band instead of two) and produces higher quality anti-aliasing i.e. closer to a box-filtered ground truth.
It may be of interest to some game/graphics devs here...
[1] https://github.com/texel-org/windfoil-algorithm
interesting. how does the AA work in your algorithm?
the reason slug has two bands is precisely because of its anti-aliasing. you having only one implies you do the AA differently, or are less efficient with searches off the main direction.
for readers: the slug shader traces two rays, one horizontally, and one vertically, to find out if a pixel is inside a glyph or outside. one would be enough for pure inside outside, but for anti-aliasing purposes it's also helpful to know how far away you are from the closest edge. but if you have a horizontal ray running parallel to a horizontal glyph edge (not uncommon), the ray glyph intersection will return no value at all. so slug traces two rays and blends between them for anti-aliasing that always works in both cases. the bands mentioned here are just acceleration structures, basically a list of cells where each tells you which parts of a glyph are contained within it.
it's still approximate. a true ground truth would just supersample and do many point-in-glyph tests within one real pixel - at edges some of them would be inside, and some of them would be outside, giving you a smooth value to display depending on the shape of the glyph within the edge pixel.
Windfoil uses boundary integrals to average winding over a given rectangular footprint (normally one pixel, independently in a fragment shader). For many cases, like typical text glyphs, this will reproduce a box-filtered ground truth exactly, i.e. for those shapes it is not approximating AA like Slug or MSDF. But because it takes the average and then applies a fill rule after, it's not an exact in all cases (fwiw, Slug can produces similar errors with tricky self-crossing curves and such).
This article has some inaccurate information since MSDF atlas doesn't have to be baked statically, so the "CJK character means huge atlas" is not really an issue if you can async upload them to the atlas.（Async outline extraction is a bit harder for C libraries, so that's why the pipeline is mostly restricted to atlas upload).
The other thing is MSDF rendering is fairly cheap and can be done on the CPU quite easily without GPU shaders, the atlas generation/upload is the expensive part, but it's a one-time cost per character per font as the atlas is just a normal bitmap texture file, MSDF text have sharp edges at most zoom resolutions, and the small size text is better handled with simple CPU raster anyways.
I really failed to see significant benefit of using Slug over MSDF + raster fallback for small fonts, it's definitely more exact, but I'm not sure if the marginal resolution benefit is worth it over much more complicated GPU dependent rendering, so I'd really want to test it out myself when I have the time over taking the word of an obviously AI written article for it.
Yes, there is at least one downside to MSDF among a set of possible downsides (huge atlas, or dynamic rebaking, or limited glyph set), and the article is written as though they all apply, which is a bit misleading. Slug is cool, glad it exists, but it isn't the right fit for my rendering project either.
Man, I am getting incredibly tired of reading LLM-generated writing
Article author here (not the lead programmer on the Slughorn project tho).
Yes, LLMs were used to help write this article and there are tells. I can smell them too.
However, as several have picked out, it's not a one-shot LLM Leeeeroy-Jenkins writing process. I am a domain expert in these sorts of things, and the source of much of the information, concept and organization of the article.
I wrote a bunch of notes and material. I then used an LLM trained on my own styleguide from my writing to organize, expand and fill in places where it was mostly gathering info from other sources. Then I went through THAT and rewrote a bunch because it doesn't always follow directions and color within the lines. It took several days of iteration to put this together even with an LLM assisting.
So, there are parts that are entirely human. There are parts that I felt were less important for me to write personally that I let the LLM writing stand, with some edits.
It is a HUGE piece of work, and writing it all by hand would have taken more time than I could dedicate to it because I have to make a living too.
I should go back and de-LLM it some more, but legit our time is spent working on Slughorn to make it better. I welcome all suggestions for edits and errata on the article (or on Slughorn itself). Our goal isn't to trash other rendering methods. It's not a competition. The post is intending just to fairly compare all of them so people can decide what technique is best for their use, because Slug/Slughorn ISN'T the right choice always, and there's so many techniques with different tradeoffs that it can be hard to grasp where your own use-case falls and how to decide.
Also, Cubicool, the primary developer of the Slughorn code will probably chime in below to address some of the more code- and feature-centric responses.
(Finally, cheers to Eric L. for releasing the Slughorn patent that made this all possible.)
What signals this as being LLM writing for you? I'm crap at noticing specifics here
Pangram 4.0 flags it as 97% AI.
There are tells in almost every sentence but some flagrant ones: “where every technique below makes its trade”, “every size you want crisp is another atlas”, “a bitmap has no idea it is being viewed in perspective”, “the fix that carried the industry for a decade”, “it lies about corners”, “built for artwork that moves”, “what separates them is technique, not resolution”, “text is where Slug earned its name”.
These are Claudisms, cloying mannered prose cliches that often anthropomorphize concepts, with an uncanny and annoying smugness.
It seemed to get more LLM-y the further down, the first thing I noticed was when it said "genuinely" in a way that didn't fit the tone. Then it said "genuinely" again. Then I started paying attention and I noticed it was basically filling up every other sentence with bullshit to sound "clever". Stuff like
> reduces antialiased vector paths into unique triangle patches and rasterizes them through a massively parallel pipeline with pixel local storage
this is typical type of LLM sentence that kinda runs under the radar, sounds clever, but if you actually look at it, none of it makes sense
- what are "antialiased vector paths"?
- why mention "unique" triangle patches? (surely it wouldn't render duplicate ones)
- a "massively parallel pipeline"? like a GPU you mean?
- "pixel local storage" sounds like an obnoxious marketing term if it's not defined in the article (which it isn't)
anyway I quickly skimmed the article after that but it was little substance
I won't try to convince anyone with specifics but it was definitely LLM generated. I think by someone who knows what topics they want to cover and did have something they wanted to post about. At a high level it is an infodump with almost no opinion expressed.
I learned a few things from it and have some interest in the topic. So this sort of a weird valley where I'm very annoyed by the writing but also getting something out of it. And it's more than I would have gotten out of promoting an LLM myself.
Which I know, because I have written a blog post about SDFs before, and I tried to author it with an LLM helping and the text just came out awful. I think I rewrote my entire post eventually - I am fairly confident at least that none of the LLM's words remained. I mention it because I've already read the SDF section of this blog largely, when an LLM generated mostly the same text 5 months ago.
Stuff like this is a giveaway for me:
> Drawing it on a GPU, crisply, at any size, under any 3D transform, while the text changes every frame, is not.
> One small texture, resolution independent within reason, one cheap shader.
English is not my native language, so I may be wrong here.
The first paragraph has this example of it's not X it's Y:
> A letter is not a picture, it is a set of outlines: closed loops of straight lines and Bezier curves, filled according to a winding rule.
Also the way the comma is used to add an inscrutable end to the sentence: "filled according to a winding rule."
For me, it was this part of the paragraph:
> There is no atlas, so a hundred thousand CJK glyphs cost a font's worth of outline data, not an atlas the size of a video. Text can change every frame at no baking cost, which is exactly what you want for live data, user input, and localized content. And it all happens in a single draw with an ordinary fragment shader, no vendor extension required.
Specifically, these sentence structures:
1. ... so <blah> costs <blah>, not <blah>.
2. And <blah>, no <blah>.
3. ... fixed resolution ahead of time, which quietly ...
They were the trained on human text right? So maybe that is the way human text as whole reads.
Maybe what we are seeing is us internet dwellers being exposed to wiring styles of humanity we had not been exposed to ?
For me it was "head to head" table. Typical complete nonsense llm-generated comparison table. Rest of the content is still quite good tbh, generated or not
Not arguing whether this article is or isn't LLM-generated, but I've seen skewed comparison tables like that in marketing since before LLMs. Pick a bunch of qualities skewed towards the new thing being proposed, highlight all the ways the new thing wins.
> A note on fairness, because the technical reader will ask.
I think it's a mix of human and LLM writing.
As much as I'm all for human generated writing, coming across and having to read through mostly-LLM-generated writing is becoming the norm (at least for me, it's true). While I may not necessarily approve of the manner in which this was written, it was still something I wanted to know more about and I read it anyway.
It does bias me negatively towards the author, and makes me a little sad that people are choosing to not put more thought and effort into their writing, but this is a trend that is here to stay.
Making a big fuss about this hasn't gone anywhere from what I can tell, and it's unlikely that the outcome will be any different going forward.
I wonder if you are more or less tired of reading LLM-generated writing than I am of reading complaints about LLM-generated writing.
Author probably didn't even read...
I think it's TLDW.
Then don't. I'm incredibly tired of people complaining about it. This is the world now. We're going to be interfacing with these models until we take the long nap. A models personality and prose are fine things to comment and give feedback on, but this belly-aching is worse than what it said in the first place because it's not constructive at this point.
As hobby project, I wrote a font rasterizer algorithm (two algorithms actually) that produces pixel perfect anti-aliased images (like Slug) using a similar but different algorithm. Rather than using Slug's clever root classifier for Bezier curves, I subdivide Bezier curves into monotonic sections where evaluating the winding number is much simpler and can be done in parallel for a group of pixels. It works nicely on GPU with warp/wave/subgroup operations and CPU using SIMD.
At first glance, subdividing the Bezier curves sounds like a bad idea (more Beziers to rasterize) but it opens doors for some parallelism, and most Bezier curves that appear in fonts are monotonic in the first place (so the increase is very modest). This was inspired by this entertaining but not very serious video about font rasterization [0].
The first parallelism optimization is checking against the curve bounding box vs. a rectangular (in uv-space) region of pixels, and this can quickly determine if the Bezier needs to be evaluated in the first place. This can be done per GPU warp.
The second optimization works only for rectilinear transformation (no rotation, skew or perspective). Solving the quadratic equation involves a square root and a division (which alone are >30% of the computation), which can be computed for each row and column of pixels instead of for each pixel (2n instead of n^2).
Both optimizations rely on mathematical invariants of monotonicity, ie. the derivative of the Bezier curve must be non-zero. All Bezier curves can be robustly subdivided into monotonic sections using de Casteljau's algorithm.
My simple benchmarks compare favorably to Slug on the GPU and to "fast" rasterization algorithms on the CPU (which is an order of magnitude faster than "fancy" rasterization algorithms with hinting etc).
Unfortunately there are so many hobby projects and so little time. All I have is messy shaders that draw individual characters and a few benchmarks to see how quickly (and something similar for the CPU). Going from there to a complete text rendering system would be a lot of work. Writing a more detailed article with illustrative code examples is something I'd want to do but haven't gotten around to.
If you want to offer words of encouragement or geek out about rasterization algorithms, I welcome any input.
[0] https://www.youtube.com/watch?v=SO83KQuuZvg Sebastian Lague - Coding Adventures: Rendering text.
Everything old is new again (in this case, 27 years old):
https://gamedev.net/tutorials/programming/graphics/s-buffer-...
https://en.wikipedia.org/wiki/Scanline_rendering
https://mcejp.github.io/2021/02/17/s-buffers.html
It works great except it can have z-fighting issues, especially near t-junctions.
I'm wondering if there's a way to calculate scan lines along 2 or more axes, then choose the ones with the least uncertainty.
A similar issue happens with convex hull algorithms. If we wrap along the x axis, we might get a different triangle mesh than if we wrap along the y or z axis, because vertices may be coplanar along an axis. I've considered wrapping along all 3 axes, then choosing the mesh that matches in the most axes.
Is there a general solution for this? Some point clouds have sets of vertices that are coplanar regardless of which axis we use. I suspect that the number of axes needed might be proportional to the number of vertices. I wonder if we could use something like change of coordinates to wrap the mesh from the frame of reference of each vertex.
If we had that technique, we could apply it to Slug and render glyphs having minimal error, regardless of how they're transformed, if we're willing to sacrifice some performance.
The permanent floating accessibility menu is irritating. I'm reading this on a tablet, and it's very difficult to not have it cover text.
Here's a simple Slug rendering example on top of sokol_gfx.h:
via WebGPU backend: https://floooh.github.io/sokol-webgpu/slug-sapp.html
via WebGL2 backend: https://floooh.github.io/sokol-html5/slug-sapp.html
There's quite a bit of helper code plus stb_truetype.h and stb_ds.h under the hood to parse TTF files and crunch the TTF curve data into the runtime format expected by the Slug shader (this stuff should better go into an offline asset pipeline tool):
https://github.com/floooh/sokol-samples/blob/master/libs/slu...
...the actual text rendering code is also taking a couple of shortcuts, e.g. no kerning, no right-to-left, and also no text shaping.
There's also a new and complete text rendering stack by Mikko Mononen called Skribidi (AFAIK not based on Slug though):
https://github.com/memononen/Skribidi
...the list of external dependencies is a bit scary for a small self-contained sample though (Harfbuzz, SheenBidi, libunibreak, etc...), but that basically shows that proper international text rendering is really damn hard, even when trying to simplify the code as much as possible.
... or why it's best to just use the OS libraries to render to textures if you only need an OSD :P
Question though, you implemented the slug system? The article mentions root eligibility but doesn't expand on it, what's the point of it because slug doesn't seem too "magical" for only doing winding counts?
“What makes glyphs hard” Another reason is hinting. Traditional text renderers like FreeType are aware of the pixel grid and they adjust the curves slightly, snapping them to that grid. For all methods in the article quite hard to do on GPUs.
“Chinese, Japanese, and Korean have tens of thousands of glyphs, and baking all of them at several sizes is a memory disaster” One possible solution is dynamic atlas built on CPU for visible glyphs only.
“The distance-field panels notch, where interpolating between stored samples no longer matches the true curve” Can’t it be fixed in the shader, using screen-space derivatives of the SDF? I think in theory, SDF value for pixel center combined with screen-space gradient vector of that number delivers enough data to compute partial coverage for the pixels on the edge.
> "In 2017 Eric Lengyel published an algorithm, called Slug, that stopped dodging. It renders glyphs directly from their outlines in the fragment shader, with no texture atlas and no per-frame tessellation. Lengyel patented it in 2019, and on March 17, 2026 he dedicated that patent to the public domain."
It's nice that he gave the patent to public domain, but this is not how patents are supposed to work. You can't patent something two years after it was already published.
I'm guessing he actually filed for a patent before publishing, and the article should read: "Lengyel was granted a patent for it in 2019"
It's an AI-written article, so maybe it's not reasonable to expect it to be consistent on this level...
* The provisional patent application for the Slug algorithm was filed on March 27, 2017, and this is incorporated into the final patent at the beginning of the Description section. A provisional patent establishes a priority date for everything it discloses (which was the whole algorithm), and it gives the inventor one year to complete the application process.
* The JCGT paper was published a few months later on June 14, 2017, after the priority date.
* The final patent application was submitted on February 1, 2018, before the one-year deadline.
* The patent was granted about 1.5 years later by the USPTO on August 6, 2019.
The details are in Eric's post here:
https://terathon.com/blog/decade-slug.html
The timeline basically checks out, maybe it simply took the patent office over a year to process the patent application?
No, application filed 2018-02-01, after the publication. Though yes it took more than a year to grant it
correction: the provisional patent application was filed before the publication, not after
He filed in 2018-02-01, after publishing in 2017. What do you think breaks in the patent system with such an approach? https://terathon.com/blog/decade-slug.html
You need to file before publishing to establish the priority date.
A sibling comment notes that he indeed filed a provisional patent in 2017 before going public. That’s the part that the article muddled. 2019 was when the patent was granted, not filed.
You can file after (within a year)
> provisional application can be filed up to 12 months following an inventor's public disclosure of the invention.
https://www.uspto.gov/patents/basics/apply/provisional-appli...
I'm the author of slughorn/osgSlug, and was surprised to find this thread. The article my boss put out a few days ago focused mostly on the "text-centric" aspects of Slug (which is what it was originally created for, afterall), but slughorn has grown into WAY more than that now. :) Glyphs are, afterall, "just shapes", and the whole experiment started with my asking: "why can't it just do ALL VECTOR GRAPHICS!?" And so ... yeah. Here we are.
We're still nowhere near the levels of libraries like Noesis or Rive (which are fundamentally different approaches to the same idea), but hey--maybe one day. There's already an impressively large stack of stuff I've been able to pull of with just some clever shader tricks, and I'm coming up with more things I want to try every day.
Right now I'm working on adding completely GPU-driven "path stroking" to slughorn/osgSlug (which uses SSBO to store/update a `slughorn::Path` and then does some `gl_InstanceID` tricks to dynamically "emit" the necessary geometric bounds Slug needs to do its analytical fill/antialiasing), and after that I'll go back to finishing the full Porter-Duff compositing stack.
There are also a handful of UIs from games I want to try "cloning" (Deadspace's diegetic style, the radio scanner from the Arkham games, etc). I also keep this HUGE directory of UIs I see in shows/movies; every time I see some mocked-up thing and think to myself, "I wonder how they did that?", I usually snap a screenshot to poke at later.
Here are some "just for fun" screenshots of interesting stuff I haven't put up on Github yet:
https://slughorn.io/funsies-00.png <- which one is 2D!? ): https://slughorn.io/funsies-01.png <- decaling slughorn-based "shapes" on 3D meshes; you can zoom until the GPU runs out of float precision
There's a whole slew of cool changes I haven't fully updated the repo with; there just aren't enough hours in the day, and we still gotta pay bills. Anyway, I'll check back later if anyone has any questions/ideas/things they'd like to see... that kinda feedback dictates what I focus on next. :)
Slug looks impressive!
The project I'm most known for is basically an MSDF shader with a bloom pass. It serves my needs 100%, though if I expand to support arbitrary text, I may reach for Slug.
The one issue with MSDF I want to raise is, it seems everybody uses the same msdfgen texture creation program from Viktor Chlumský's master's thesis 11 years ago. I wish there were other implementations. Who ever heard of a graphics technique that was only ever programmed once, and then used everywhere without substantial iteration? We need to de-XKCD-2347 MSDFs for everyone's sake, including and especially Chlumský.
> Who ever heard of a graphics technique that was only ever programmed once, and then used everywhere without substantial iteration?
while I agree with your general point, since you're asking, the table from Paul Bourke's marching cubes code comes to mind:
https://paulbourke.net/geometry/polygonise/
another one is the "fast hash" GLSL pseudo random number generator that everyone copies from Inigo Quilez:
despite those constants clearly being the result of some keyboard-bashing, they are copied far and wide :-)I haven't heard of Chlumský or MSDF before, but I think a lot of people have been aware of the technique before he published his paper, thanks to Valve's TF2 text rendering paper:
https://web.archive.org/web/20120505013814/https://www.valve...
The pdf details only simple SDF, but in the closing paragraphs, it mentions the weakness of the technique and mentions how it can be solved with multiple SDFs, but the exact technique wasn't showcased.
Which led to people trying to reverse engineering it, and making their implementation, for years (it's Valve after all). Including me. Not sure if what I came up with was exactly MSDF, but certainly there are a lot of implementations out there.
We mostly agree! I should elaborate.
I'd say what you and the others did was research, not implementation. Your results were solutions to the same problem, not variations of the same recipe. What you did is important but separate from what's concerned me.
A recipe of Chlumský's— the msdfgen utility— is widely used, but only has one producer. I'm just saying that that's a liability. Like, imagine if HarfBuzz was the only text shaper, and was maintained by one person.
Interesting read. Text rendering techniques have always fascinated me.
I'm a bit confused because at some points it seems like the author is conflating "tessellation" and "Rive". Are they the same thing? As an uneducated reader, my understanding would be that Rive is an implementation of a renderer using the tessellation approach. But surely a generic tessellation approach could support perfect arbitrary transformations even if Rive doesn't?
Maybe there's something I'm missing.
Also, a nitpick: in the "head to head" section, the author highlights Slug's better performance in green for the entries that it wins (or ties). For the sake of fairness, shouldn't we highlight the winners in every category? Surely Rive's "low" memory usage beats Slug's "moderate"?
> But surely a generic tessellation approach could support perfect arbitrary transformations
Yes, but at typical font sizes this generates a lot of tiny triangles (0 to few pixels) which perfoms badly on GPUs.
Somehow this ended up next to
https://news.ycombinator.com/item?id=49909610
MSDF looks better than Slug for me in the first example.
But slug wins in perspective in my eyes.
I use MSDF to render crisp text in my webgl hobby game. Hope to publish it with source code when I get the time.
thanks for sharing the article. I'll take a deeper look at it later.
I do MSDF as well and since I'm not doing a huge-ass text editor (and even then) it works and it's great. One thing to consider is that with any solution that does things directly from vector outlines means you also then have to distribute proper font outlines and you might not have a license to do that. With MSDF and similar atlas-like solutions, you pre-render a font and distribute that rendered image instead of an actual font.
Which you also might not have the license to do. I once licensed a Monotype typeface that prohibited its use in anything editable, including fillable PDF forms.
MSDF corners gave me trouble til I bumped the distance range at small sizes.
Is there a runtime comparison of the shaders needed? Seems like you might have to do a lot of texture sampling if you have to walk the ray through the data but maybe there's a trick?
MSDF is pretty much just the target texel in question plus the surrounding samples in a way the GPU can do entirely upfront before the math starts. (M)SDF glyphs also play nicely with mip mapping and I would think this Slug algorithm needs uncompressed data. Maybe that doesn't matter because you just don't scale the data ever?
Slug doesn't use "bitmap" font data but more like parameter lookup tables in storage buffers, pre-processed from TTF files. The lookup data can of course also live in textures (so that it works in WebGL), but using those textures as "poor-man's storage buffers", e.g. fetching the data directly without filtering.
The pixel shader is indeed quite complex compared to SDF:
https://github.com/floooh/sokol-samples/blob/8afa83928ce1870...
There's another GPU text rendering algorithm missing from the comparison: Rook & Possum's Scanline Sweeper:
https://rookandpossum.com/posts/scanline-sweeper/
Sean Barret (creator of the stb public domain libraries) independently invented a CPU-based implementation of the same idea, used in stb_truetype.
I knew the second Eric posted about releasing Slug to the public domain we'd get 100s of "OpenSlug" slopped-up. Will be interesting to see which implementation will win or if Slug will keep being a thing.
Tbf, the Github repo doesn't look particularly 'sloppy' to me, more like some mild AI assistance. There's several months of fairly regular looking git history, a couple of commits with an LLM disclaimer for python bindings, and two llm-context files.
https://github.com/AlphaPixel/slughorn
Yeah, I (author) regularly use AI (anyone who doesn't is ... well, they're not seeing the same reality I am, anyways :)), but I don't just "turn it loose." It reviews my initial passes, catches stupid mistakes I make, and often has good advice about "Hey, don't overengineer this", although I _do_ have to regularly reign it in from other complete nonsense (which kind of makes me happy, because it means, you know, I still have a job). For slughorn, it mostly did some of the C++ tests, almost all of the pytest coverage, the pybind docstrings, and the GLFW example (since I do 99% of my own testing with OSG until I finish there and move on to Vulkan).
Go look at the actual git history.
Slughorn is coded by hard-working humans. Sure, we use LLM tools for some investigation and development, but this is not an AI slop project. It's been in the works steadily since not long after Eric announced the patent release, grinding through improvements with every hour of the day we can dedicate to it.
Every important line of code here was written, tested and is understood by Cubicool, the lead programmer (there are some LLM-generated ancillary parts of the codebase, and I think git shows those).
I must apologize, this really came across as an accusation. I meant to say that, upon his announcement, I imagined there would be many 1-weekend slop clones. I have not looked at slughorn, but I really think this is cool, and I appreciate competent people working on cool problems. I'll keep an eye on this! Will be more careful with how I express myself, sorry! :)
Excellent write up. The cited references are on point too. Eric Lengyel is a legend.
> By Chris Hanson
What a name!
(Skipped the rest of the article cause it's AI.)
Chris "Xenon" Hanson here.
Take a seat over there.
And then go read my reply above about how AI was and was not used to write the article.
I'm looking forward to your competing article that does it better without using AI.
Hey, all the power to you. It doesn't really matter how AI was used, cause I can't tolerate its language! That's why I said I skipped the article instead of accusing it of being bad or whatever. It's a perfectly fine article, just not for me.