8

I have to extend an OpenGL-Rendering system to support international characters (especially Hebrew, Arabic and cyrillic).

Development platform is Windows(XP|Vista|7), alas using Embercardero Delphi 2010.

I currently use wglOutLineFont(...) to build my font's display list and glCallLists(length(m_Text), UNSIGNED_SHORT, PWchar(m_Text) ) to render my strings.

While this is feasible for Latin-1 Characters, building the full Unicode character set in advance is pretty time-consuming (about 8.5 minutes on my machine), so I am looking for a more efficient solution. I thought about limiting the range from u+0020 - u+077f (Latin, Greek, Cyrillic, Arabic and Hebrew) to include just the glyphs I need, but that would just be a solution for my current needs, and will become insufficient once other encoding is needed.

On the upside, I do not have to worry about left-to right or right-to left direction as our application can handle this already.

I would expect this to be a well-known problem, so I would like to ask if there is any reference material on this on the web, or if you could share some insight on this?

Edit A clarification: I use a polygonal font representations. Each Font is constructed at unit size (1.0) in advance and scaled appropriately using glScalef(...) before rendering. I did decide against pre-rasterizing since the users might zoom in quite closely (The application is used for CAD), so rastering artifacts would become visible.

Additionally, since a scene seldom exceeds more then a few hundred characters (mainly labels and measurements), the speed gain from pre-rasterization is negligible.

Cœur
  • 37,241
  • 25
  • 195
  • 267
sum1stolemyname
  • 4,506
  • 3
  • 26
  • 44

3 Answers3

3

Don't pre-build the display lists :- create an intermediate sprite that builds the lists on demand, and caches them. Trying to pre-compute lists - or pre generate rasterized textures at every font size, font face, and for all characters, is impractical, Especially when you scale to far eastern character sets.

Chris Becke
  • 34,244
  • 12
  • 79
  • 148
  • Using vertex buffer objects would be very nice! Font rasters could be in high resolution, then mipmaps and multisampling do the rest. – Luca Mar 15 '10 at 21:23
  • So you mean i should generate the lists once I know which characters i will need to draw for a given String? – sum1stolemyname Mar 16 '10 at 06:52
  • Yes. Facing a similar problem - and useing the OpenType library (For platform idependence rather than wgl) we went with rendering rasterized textures containing renders of words. We then cache the visible words, and discard any words that have been scrolled off screen. Our application only shows a small amount of text, without very complicated formatting requirements, but there is enough potential text that pre-rendering it all would incurr visible delays. – Chris Becke Mar 16 '10 at 07:39
2

You need to replace the wglOutLineFont.

To do that, generate/render to texture the required glyphs using the wglOutLineFont, and then save the texture into a raster image file. Once application loads, it needs to load the texture image and the glyph texture coordinates (4 coords for each glyph), and to generate the display lists (one list for each glyph, each display list shall draw a single glyph as textured quad).

Each short representing a glyph shall have a corresponding display list (their value much match, and glListBase can aid in this).

I suppose loading a texture is faster than generating font display lists at runtime. Pratically you move offline the glyph raster computation. But the display list generation can be heavy (many glyphs). Indeed you can run in a separated thread the display list generation or generate only the display lists required by your needs.

Luca
  • 11,646
  • 11
  • 70
  • 125
1

I've had good luck transliterating this tutorial into C++, though I'm not sure how well it will transfer to Delphi.

genpfault
  • 51,148
  • 11
  • 85
  • 139