OpenGL live text-rendering

Question

I'm implementing a GUI built on top of OpenGL. I came to the problem that each GUI will have -- text rendering. I know of several methods of rendering text in OpenGL, however, I'm wonderin which of them would be best suited for a GUI.

Generally in a GUI we have two types of text -- static and live. Static is easy enough -- we can render a TTF to a texture and forget about it. It's the "live" text that is more bothering me -- imagine console, or a live chat in a multi-player game.

I thought of several options:

• no special cases -- render and load a texture each time the text changes, keeping in mind only to rerender it when actually new text appears, and trying to split the larger text into small parts (like per chat line). However this would still leave us hanging in cases like a score line that changes all the time, or a intro text that renders "per character" (typewriter style seen in some sci-fi games)
• quad-per character -- this also seems a popular solution, you prepare a texture with the ASCII table and render a textured quad character. However, I have serious doubts about the efficiency of such a solution. Tips how to make that faster would also be welcome.
• hybrid solutions -- however I have no idea how to implement that cleanly

The question hence is -- how to render text in OpenGL efficiently?

(if this helps, I'm coding in STL/Boost-heavy C++ and aiming at GForce 6 and later graphics cards)

Any suggestions welcome.

Answer 1

EDIT: another code gem that's worth a look is Font Stash.

---

You can create a texture in which you render all the characters of your font. Then you just draw textured quads with orthographic projection and proper texture coordinates: this approach works when your text is in a language that doesn't contain much symbols: like english. The font texture is created once at the beginning of the application and then rendering quads is really fast.

That's what I'm using and I believe it's the fastest way to render text in OpenGL. At first, I used Angelcode's Bitmap Font Generator tool and then I integrated FreeType directly and built a big texture containing all the glyphs at application launch. As for tips to improve the quads rendering speed, I just used VBO as for the rest of the geometry in my application.

I'm surprised you have doubts about quad rendering while you don't seem to worry about the performance of generating a texture on the cpu, then uploading it, then binding it to finally render a rectangle with it, that for each frame. Changing OpenGL states is the bottleneck, not the 500 - 1000 quads you'll use for text.

Also, have a look at libraries like the FTGL library who converts the whole font into polygons (geometric fonts).

Answer 2

Try reading this: http://dmedia.dprogramming.com/?n=Tutorials.TextRendering1.

The approach described is the typical method for text rendering with graphics APIs. One character per quad, and all of the image data for text in a single texture. If you can fit your entire character set into one texture (actually, depending on the size of the texture, you might be able to fit several) the rendering is extremely fast.

The key is that texture binding is the operation you need to minimize. If you can render all of your text with a single texture, it won't matter how much text you need to put on the screen. Even if you have to switch textures a handful of times (different fonts, different font attributes [bold, underline, etc]) performance should still be good. Text performance might be more critical for a HUD, but it less important in the GUI.

Answer 3

Per quad character handled thought a display list (updated only when text changes) is quite enough for most cases.

I used it with X11 fonts using the XLoadQueryFont, glGenLists, glXUseXFont, glCallLists you have an array of display lists describing each character.

the glCallLists function accepts a char * argument for your text and it can be embedded inside a display list.

So you end up with a single call to display blocks text.

The font texture suggested by G. Pakosz is similar, but you compute your own "by character" display lists.

Your first options will be quite slower as it will require processor based rendering at each text change.