nanogui: NanoX version 0.3 released
Subject:
RE: NanoX version 0.3 released
From:
Greg Haerr ####@####.####
Date:
11 May 1999 23:41:12 -0000
Message-Id: <01BE9BD5.BEE7BC70.greg@censoft.com>
On Tuesday, May 11, 1999 4:16 PM, Vidar Hokstad ####@####.#### wrote:
> On Tue, 11 May 1999, Greg Haerr wrote:
>
> > > Some of the code for the prototype could be useful for nano-X, though -
> > > I'll take a look at it. For instance, I wrote some font handling code that
> > > use font files that are a lot smaller than nano-X's (at least as of 0.2,
> > > haven't had the time to check out 0.3 yet).
> > >
> > > Vidar Hokstad ####@####.####
> > > Director of R&D, Screen Media AS
> >
> > Ben stated that he was working on adding font handling code to read in font
> > files... The font code hasn't changed in 0.3. I would be interested in your comments
> > for small font mgmt. Are you looking at compressed raster font data, or something
> > more exciting?
>
> Nah, nothing exciting, really, just staying within the smallest number of
> bytes pr. line, instead of 4, but since that's a pretty obvious
> improvement to make Ben's probably thought about it if he's fixing the
> font code. I also have some code for converting BDF fonts to that format.
You might want to send Ben this code...
>
> I think it should be fairly easy to pack it further without too much of a
> performance hit, though... I'll think about it and do some tests.
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...)
>
> One issue though:
>
> Consider supporting more than one font pr. file, and mmap()'ing the file
> instead of allocating memory for it, and reading it in. For those of us
> with tight memory requirements using mmap() would mean that the kernel
> can page the font data in and out without any swap space. This holds for
> most other things too: the more cases where mmap() can be used over
> malloc()'ing some memory and reading in a file, the better it will
> generally be for the minimum required memory footprint.
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(). Of course, all this code is in the device-dependent
section of nanogui. This means if you have very special requirements, you can write/modify
your own specialized driver.
At the mid-level, I can't assume the OS supports mmap().
Greg
>
> Regards,
> Vidar
>
