It’s 2015 and drawing text is still hard | Hacker News Reader

It’s 2015 and drawing text is still hard

engineering.eventbrite.com

37 pointsparris17 comments

I have been working a lot with WebGL text in the past several months. Our current solution uses SDF with standard derivatives (crisp anti-aliasing regardless of zoom level) and supports kerning (depending on the font), batched glyphs, and word wrapping. It's not perfect, but it's pretty good for common use cases.

Since the OP is using modules already, they might enjoy some of the libraries and tools here:

https://www.npmjs.com/package/text-modules

Or a ThreeJS specific implementation of bitmap / SDF:

https://github.com/Jam3/three-bmfont-text

And lots more reading on the subject:

http://mattdesl.svbtle.com/material-design-on-the-gpu

Some practical implementations of it:

- npm dataviz: http://mattdesl.github.io/npm-names/ (over 40k glyphs, could go higher)

- physical text: http://mattdesl.github.io/physical-text/index.html

Whoa that's really cool!

Drawing text is hard, and not something that should be solved at the OpenGL level. It involves coordinating with the window manager and user settings.

But I'm just responding to the gimmicky title. It looks like the article has some interesting technical content to it.

I agree for the most part. For a lot of cases we did use tooltips, overlays, and sidebars. That isn't a cure all though. Without embedding text we couldn't really give enough context to the end user.

> Drawing text is hard, and not something that should be solved at the OpenGL level.

Agree completely with the first part, less sure about the second. Almost everything needs to do it. Text rendering was included in OpenVG, which seems to have flopped completely. And rendering anything to the screen with OpenGL will involve coordinating with the window manager.

Mark Kilgard's gigantic NV_path_rendering extension included a LOT of font/glyph support. It surprised me as well when I first read it, but there's some interesting discussion of the rationale in the second item of the Issues list at the end of the spec [1].

[1] https://www.opengl.org/registry/specs/NV/path_rendering.txt

For certain applications, it makes sense to solve it outside of OpenGL. For other applications [1][2], it makes more sense to utilize the GPU directly.

[1] - http://mattdesl.github.io/npm-names/

[2] - http://mattdesl.svbtle.com/material-design-on-the-gpu

Google "loop blinn". There are a few papers by those guys on the topic of rendering smooth anti aliased cubic bezier paths, which is really what you want.

You can read font data directly from ttf e.g. And render text nicely with few polygons and shaders taking care of very nice accurate edge rendering.

I wrote a half finished c implementation a couple of years ago that might be useful as a reference if you want to look into this more : https://github.com/hansent/lbfont

It's mainly based on the paper/article inter book GPU gems 3.

Accelerated 2D Vector graphics are hard, when I was working on this nvidia was announcing the nv_path_rendering extension; don't know how widely this is supported these days. But I doubt it's available in webgl.

Edit: few typos...writing on mobile

Feel free to do a PR with your solution, just so no one has to write a "It's 2016 and drawing text is still hard" blog post next year ;)

Ha! I might split out the code into its own repo so it can be used as an add-on library for ThreeJS. I think the code here might push it over the 100kb limit. We'd also need to get a license to SDF'ify a default font (possibly Helvetiker). We had to get permission to do it with our font "Benton Sans".

I have been building a tool for interactive data visualization using panda3d. Running absurd amounts hideously complex static geometry? No problem. Want to render short labels on a couple thousand objects? Draw calls aside, renderer slows to a crawl because it also uses the text geometry approach. Does anyone know if there are other approaches that work aside from the the SDF described in the article?

If you don't need to scale/rotate your labels, SDF is massive overkill; a simple texture font (generating one quad per glyph) is fine.

If you are OK with (a) processing font atlases offline and (b) simple languages (no complex text layout) then SDF fonts is a really great solution. It's fast, memory efficient, easy to anti-alias, and real-time effects (shadows, edge fuzz, etc) are easy to add.

This site looks terrible in chrome.

https://i.imgur.com/39warVl.png

Which version of Chrome / which OS are you using?

Did a quick check and it looks fine in Chrome v44 on OSX 10.11, Windows10 and Android.

More on-topic: text rendering is a hard problem, kerning and UNICODE support is only the beginning of the rabbit hole. Once you need to render Arabic, you also need bi-directional text rendering (normal text is RTL, number and latin-characters-strings are LTR), and you also need context-sensitive glyph-shaping (the same character is rendered differently depending on whether it stands alone, at the beginning, end or middle of a word).

This still happens to me frequently on my Win7 laptop.

Who or what says it should easy?

Reply on news.ycombinator.com