Re: Re : Re : [Chicken-users] Scheme (LISP) editing

[Shawn Rutledge]

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?