nanogui: Scalable font support ...
Subject:
Re: Scalable font support ...
From:
####@####.####
Date:
21 Mar 2000 08:11:15 -0000
Message-Id: <20000321080114.28185.qmail@nameplanet.com>
On Mon, 20 Mar 2000 13:30:50 -0700 "Greg Haerr" ####@####.#### wrote:
>I have tested the t1lib stuff that I rewrote, and it doesn't seem to have the
>memory leaks that FreeType is showing. Overall, I'm fairly happy with the
>t1lib stuff (I haven't benchmarked either for their actual memory usage, I'm
>just trying to get the stuff to run reliably)
>
>Basically, there's now a create_font and unload_font entry point
>in the font rendering subsystem. The font's are loaded for as long
>as the application that called GrCreateFont wants until GrUnloadFont
>is called. All "application data" from the font rendering libraries is
contained
>in a Microwindows data structure. However, I have no idea how or
>about how much data is cached unseen from the applications program
>by the libraries.
>
>
>Vidar - thanks for posting; I'm anxious for your comments on the fonts
>implementation.
I haven't had the time to look it over yet. Maybe tonight. With T1lib
the main problem is likely to be that T1lib does *lots* of internal memory
allocations. If you for instance load a font with T1lib, and then draw with
more than one size, there will be lots of cached data for *every* size you've
rendered glyphs in. This can be "fixed" by turning caching off (very bad for
performance), or by deleting the font size information at certain points (I
tested allowing it to keep a certain number of sizes, and then systematically
deleting all size info above that number, and that worked reasonably well - most
apps only use a few sizes).
Another issue is just plain lousy memory management internally in T1lib,
especially in the code written by Adobe. If you strace Nano-X with T1lib linked
in, and grep for malloc(), you will see what I mean... I looked briefly into
creating a patch for it that allocated pools of 8KB, and returned pointers to
blocks within that pool for each allocation, and that speeded things up a lot,
and helped memory use tremendously (the allocations in question only happen
when a font is loaded, and the free()'s only happen when it's unloaded), but I
never got around to cleaning up those patches... I'd be happy to give pointers
if someone wish to have a go at it, though.
Regards,
Vidar Hokstad
--
Get your firstname@lastname email for FREE at http://NamePlanet.com
