nanogui: Scalable font support ...
Subject:
Re: Scalable font support ...
From:
####@####.####
Date:
20 Mar 2000 20:12:45 -0000
Message-Id: <20000320200245.9708.qmail@nameplanet.com>
On Mon, 20 Mar 2000 11:53:41 -0700 "Greg Haerr" ####@####.#### wrote:
>: For truetype fonts with freetype, glyphs aren't cached in the library,
>: but in the user application using the library (in our case, microwindows)
>:
>: I haven't done it yet, but that will be the next step ....
>
>Martin,
> Thanks sooo much for putting together the initial work on FreeType.
>It's a great addition to Microwindows. I've added all your stuff, with
>heavy hacking to fit into the engine. I'm very interested in your feedback.
>
>With the new design, you can have adobe and truetype fonts concurrently
>if desired. I have purposely left out a GrSetRotation for now, as well
>as GrSetAntiAliasing, since they involve some subtle issues with GC
>caching. Instead, the global variables need to be modified. I'm
>debating whether all "style" issues like kerning, antialiasing, and rotation
>should be set at once, rather than with separate calls. There's also the
>issue of recomputing the matrix values.
>
>Anyway, I'd like you to check out the t1demo.sh program, which
>displays many different fonts and sizes using FreeType. The problem is,
>that the program gets _really_ slow after about 30 seconds, and it appears
>that the process begins swapping, so we have a huge memory leak, IMO.
>I tried to debug it, but couldn't find anything. Can you?
I had similar issues when I worked on the Type 1 support via T1lib. It turned
out that even stopping caching of glyphs wasn't enough, since T1lib create
separate font structures for each size used (which was particularly bad since
my test program scaled the font by multiplying the previous used size by 1.01
:-) and store misc. metrics data for each size, unless you explicitly deleted
the sizes you didn't need anymore.
It's possible FreeType does something similar, even though it doesn't cache the
actual glyphs.
Btw., if anyone wants to optimize T1lib for memory, the place to start is the
AFM parsing functions written by Adobe... Their memory handling is horrible
(they keep doing malloc() of blocks of data down to 2-3 bytes, and *lots* of
them...)
Regards,
Vidar Hokstad
--
Get your firstname@lastname email for FREE at http://NamePlanet.com
