> > > GL text drawing has been recently implemented in 3 steps on Mac OS: > > 1) draw text to a bitmap using standard OS text drawing routines > > 2) convert this bitmap into a GL texture > > 3) map this texture to the GL scene > > When was this implemented? This came with the cocoa-ization of FLTK (r7027).
> > As of Sunday evening, testing on my OSX 10.4.11 PPC box, GL text > rendering was not working. Thanks for pointing that. I had not tested the ppc architecture. I have now put back the old algo (with its drawbacks) for the ppc architecture. Cube and fractals now display text as needed also with ppc. > > Also, STR #2342 refers, which I raised on Saturday. I believe I will close this one now. > > > > Because the pile height has no obvious universal adequate value, > > I have added 2 mac-specific functions: > > void gl_texture_pile_height(int max); > > int gl_texture_pile_height(); > > to set and get the texture pile height. > > Not keen on that - how can the programmer know what is a sensible thing > to set these too? > Can we do something at runtime to allocate RAM dynamically based on > <something> e.g. installed RAM or such like...? > > This is an annoying aspect of this solution to improve the speed of GL text rendering. The rule is simple: set the pile height to the number of simultaneously displayed strings on a GL scene. This rule is mentionned in the doc. The situation is that we --have to-- do some texture pre-computation or else GL becomes annoyingly slow. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
