nanogui: NanoX version 0.3 released
Subject:
RE: NanoX version 0.3 released
From:
Vidar Hokstad ####@####.####
Date:
12 May 1999 11:43:58 -0000
Message-Id: <Pine.LNX.4.10.9905121327340.2715-100000@a.ncg.net>
On Tue, 11 May 1999, Greg Haerr wrote:
> You might want to send Ben this code...
Will do as soon as I get home today...
> In order to draw quickly, the font data really should be decompressed
> so that the low-level font code isn't dealing with having to deal with it. This would
> allow the font code to be "side-attached" to alot of other's lower level driver
> code, without all the driver writers having to worry about all sorts of font complications
> (which, along with color mgmt, which we haven't talked about, can consume years
> of one's life...)
What I was thinking about wasn't any type of funky advanced compression
algorithm. I still think there's a few optimizations I can do that won't
add much size to the font handling code, but that could shrink fonts
without any noticeable slowdown.. I have some ideas I'll be testing
tonight.
> I like the idea of multiple fonts per file.
>
> In regards to mmap(): operating systems that support mmap() are already
> using alot of ram. I don't think that nanoX with any number of fonts is going
> to exceed the ram in machines running mmap().
The problem isn't that nanoX + fonts exhaust ram... But when you're
running Mozilla etc., every byte count. And when you already have the data
in flash, using mmap() is a very simple way of reducing the amount of
non-pageable data (since we don't have anywhere to place a swap
partition). For our use, we'll be mmap()'ing almost everything because of
that.
> At the mid-level, I can't assume the OS supports mmap().
You won't have to. I could write a small wrapper function for you to load
a file that use mmap() if it is supported, and that use malloc() and
read's the file into memory if mmap() isn't supported. We're talking <10
lines of code.
Regards,
Vidar
