Hacker News Reader

Comment by Negative1 | Hacker News Reader

What I like most about this technique as opposed to other "draw a font as curves in a shader" approaches is that it's actually very fillrate friendly. Instead of drawing a quad and calculating curves (or curve segments) over all of those pixels/fragments, you draw the font outline in polygons which restricts where pixel processing occurs. The whole thing actually reminds me of Carmack's Reverse stencil shadow technique (which grave nice crisp edged shadows but also stopped pixel processing for shadowed regions).

"The code is open source on GitHub in case it’s useful as a reference"

Thank you!

"it’s written in the Skew programming language"

:-(

Thankfully the shader code is in GLSL as you would expect/hope.

View on HN

Well, I'm a bit confused as to how this is fill-rate friendlier than something like [1]: if you are drawing and checking the winding rule via the stencil buffer or color buffer, then you're going to overdraw a lot. A technique like [1], on the other hand, only paints each pixel once.

I would think that, compared to the LUT texture approach, this technique is lighter in FS load but more expensive in terms of fill rate/ROP.

[1]: http://wdobbie.com/post/gpu-text-rendering-with-vector-textu...

Stencil check rejections based on overdraw don't hurt as much as you'd think. Liken it to a clip() (or discard), which is a single instruction. The GPU pipeline optimizes for this.

The approach you linked too is very well thought out but each font still does pixel processing for a bezier curve, which is many orders more expensive than a clip(). Never mind the addition of a dependent read via the LUT and the tracing step.

A word of caution, not all pipelines are created equal(wrt to stencil/z-test/etc).

One other downside is this technique requires two drawcalls which can be pretty painful on some platforms.

Unless you really need large ranges of scale a glyph atlas based solution will probably be the fastest on a wide range of hardware.

The Skew language compiles to Javascript, C#, and C++ (which is still a work in progress). So if you don't like that it's in Skew, you might have the option to switch it to one of those languages. It probably won't work for the more system-dependent parts of the code, but you might get something out of it.

> Thankfully the shader code is in GLSL as you would expect

That's not necessarily what I'd expect, given that it's from Microsoft Research. I know they're a pretty independent bunch, but still, kudos.

You've misread; Evan says that he based his calculations on a Microsoft paper. Not that he works for Microsoft or that this is Microsoft Research or anything like that.

Whoops, you're right, I was way off. Thanks for the correction.

Reply on news.ycombinator.com