OS native 2D API vs OpenGL

Question

Suppose I wanted to create a text editor from scratch.

I searched around and everyone suggested using OS-specific native 2D APIs (e.g. GDI+ in Windows or XLib in Linux), especially for font rendering.

My question is: why is it that openGL isn't suited for such a task? Why is it so hard to render antialiased text and controls as in a text editor with openGL and why should I prefer the non-portable way of native 2D OS APIs?

Answer 1

Part of the difficulty is that OpenGL doesn't provide a font engine or any capabilities specifically for rendering text. In other words, it's not a matter of OpenGL being poorly suited to the rendering part of the task, just that OpenGL is missing a lot of pieces necessary to the task.

To render text under OpenGL, you'd typically start with some font engine to take (for example) a TrueType or OpenType font, and render a glyph from its info (e.g., FreeType). Then you need a text display engine to figure out how to render characters to display your strings decently. In a simple case like English, it has to handle things like kerning and leading. In a complex case like some Arabic scripts, you basically need kind of a feedback loop between the text rendering and the font rendering, because a glyph can take a different form depending on its context in the string.

In short, writing a text editor that renders its text via OpenGL means re-building a lot of a text rendering stack from the ground up.

If you don't care a lot about rendering quality, you might be able to get by with just rendering a few fonts to bitmaps, and displaying your text using them. This can simplify the code quite a bit, but a simple implementation will mean producing output that looks something like an MS-DOS command line. Even matching the output quality of, say, Windows 3.0 will take a fair amount of work. That's not to say it can't be done--but it could dwarf the difficulty of writing the editing part of the text editor.