chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: minh thu
Subject: Re: Re : Re : [Chicken-users] Scheme (LISP) editing
Date: Fri, 2 Mar 2007 21:15:53 +0100

2007/3/2, Shawn Rutledge <address@hidden>:
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?


Making one polygon per word, you have to create the texture every time
then ? I don't know, in fact I won't try to benchmark that :)
And in this case, since the primary purpose is repl/editor, one
character at a time is fine.

The opengl egg : I don't like its syntax but I'm nitpicking, I use it now :)

Cheers,
thu




reply via email to

[Prev in Thread] Current Thread [Next in Thread]