On 3/2/07, minh thu <address@hidden> wrote:
> 2007/3/2, Shawn Rutledge <address@hidden>:
> > How are you rendering the text? The choices are (AFAICT) use freetype
> > to generate bitmaps (maybe build a bitmap for each character/font
> > combination, or maybe render a word at a time or a line at a time) and
> > display them using glBitmap; use freetype to generate antialiased
> > pixmaps (same choices for characters, words or lines) and use them as
> > textures on top of polygons; or somehow convert the font to vertices
> > and render the text entirely as filled triangles. I didn't see a way
> > that the results of glBitmap can be transformed - it goes straight to
> > the framebuffer, right? Besides not being antialiased. The third
> > method (vertices) might be slow (or is it nowadays?) So I figured the
> > second method (textures) has the most promise. But ideally it should
> > leverage the power of the GPU somehow, rather than involving Freetype
> > for every line of text every time it's drawn. If you render a word at
> > a time, you can save them to GPU memory as textures and re-use them
> > every time that word with that font is shown, while still making use
> > of Freetype's hinting. If you render a character at a time, the set
> > of textures becomes smaller, and you gain the ability to transform
> > each character (like for doing text along a path, for example) but
> > have to do hinting yourself.
>
> From freetype, I'll query each glyph as a pixmap (8bits) and store
> them in a single array of unsigned char. Yes, I do this C side because
> I don't want to write a freetype binding.
> Once it's done, I upload the array into video memory as a single
> texture. Then I create a display list for each char. To render a
> string, just call glCallLists. The c array is released since the
Well you could use display lists for vertices too, so it's nice to be
using the same call either way to actually do the rendering.
> texture is held by opengl.
> (I say "I" but I just used the technique from fltk and/or fox)
>
> One think is a bit problematic : "each" glyph/char means nearly all
> 8bits ascii code, i.e. 256 chars. So there's no utf-8 support right
> now. I don't know yet how to handle it, probably a system of cache.
I understand, thought about that too. I would want to have UTF-8
support somehow, eventually. It could be done with code pages
(translate runs of text from UTF-8 to language-specific code pages and
then use different display lists for each code page). Maybe too much
trouble...and anyway it doesn't work for some Asian languages that
don't fit in 8-bit values. But if you take the "one big font"
approach, there would be more display lists to have one for each
character, than if you have one per word. I also suspect it would be
more efficient to render a word at a time (one polygon for each).
> If you find the thing not correct, just keep in mind it's early code
> and I've nearly no experience ... and of course I accept help :)
Yeah we are both hoping to release as open-source in the end.
I was also wondering what you dislike about the existing OpenGL egg?
You started over, right?