nanogui: Thread: NanoX version 0.3 released

> 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

But the font is in the server.

> 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.

The only thing to watch there is that mmap isnt available on all platforms
(eg Linux 8086)

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

On Wed, 12 May 1999, Alan Cox wrote:

> > 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
> 
> But the font is in the server.

Now it is, but Greg mentioned that Ben is adding support for loading extra
fonts.
 
> > 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.
> 
> The only thing to watch there is that mmap isnt available on all platforms
> (eg Linux 8086)

I know, but in that case we could just malloc() a memory section, and read
the file into it. Of course neither would be good alternatives if you
store fonts in a format that require processing when you read it in, but
the format BOGL uses now is easy to modify so that isn't necessary.

Regards,
Vidar

Speaking of w??????? CE, that's what my nano-Win will compete with!

On Wednesday, May 12, 1999 1:07 AM, Alexander Peuchert ####@####.#### wrote:
> On Tue, 11 May 1999, Alex Holden wrote:
> 
> > On Tue, 11 May 1999, Alexander Peuchert wrote:
> > > Same for me, if my Geofox will ever be built :-(.
> > 
> > Yes, I know, mine still hasn't arrived either. They have promised that it
> > is about to be built, and mine will be one of the first of the next batch
> > to be despatched, but I've yet to see it...
> 
> They said, mine would be built this week. But I'm a little bit sceptic,
> ... also with the shipment to germany.
> 
> > 
> > > I think, additionally the glib and a windowing system like nano-X is
> > > needed. And space for the apps and execution space and space for the
> > > kernel and ...
> > 
> > Yes, but:
> > 
> > [root@hyperspace stuff]# ls -l
> > total 1205
> > -rw-r--r--   1 root     root       153056 May 11 15:25 libgdk.a
> > -rw-r--r--   1 root     root       106248 May 11 15:23 libglib.a
> > -rw-r--r--   1 root     root       965768 May 11 15:25 libgtk.a
> > [root@hyperspace stuff]#
> > 
> > libglib is only 100KB or so, our gdk can probably be kept down to 100KB or
> > so, and there may well be some stuff we can strip out of gtk+. Plus, if
> > they are physically stored on CF, then only the code which is being used
> > will get mapped into RAM... I think the 8MB of the Psion 5 might well be
> > too little to run any largish GTK+ apps, but the 16MB Geofox ought to be
> > able to cope (I hope).
> 
> But I also want a Linux PDA suite to run on both without any CF. Otherwise
> the w?????s CE people will laught at us.
> 
> > 
> > > I can't tell you, if that would give a usable system. I want to use 'my'
> > > geofox on a daily bases, if possible, not as a technology study.
> > 
> > Well, I'd like to use mine for both.
> > 
> > --------------- Linux- the choice of a GNU generation. --------------
> > : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
> > -------------------- http://www.linuxhacker.org/ --------------------
> > 
> 
> - alex
> 
> Alexander Peuchert
> ####@####.####
> http://www.peuchert.de ( not very interesting yet ;-) )
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 

Geez, combining Mozilla and nanoX sounds like David and Goliath, 
or is it Godzilla and humans... ;-)

On Wednesday, May 12, 1999 5:39 AM, Vidar Hokstad ####@####.#### wrote:
> 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
> 
> 
> 
> 

Like I mentioned before, all this code is completely contained in one device-dependent
screen driver file, at the lowest level of the nanogui engine.  So, a custom driver
can be created that does exactly what you want, with no change to nanogui.

Greg

On Wednesday, May 12, 1999 5:46 AM, Vidar Hokstad ####@####.#### wrote:
> On Wed, 12 May 1999, Alan Cox wrote:
> 
> > > 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
> > 
> > But the font is in the server.
> 
> Now it is, but Greg mentioned that Ben is adding support for loading extra
> fonts.
>  
> > > 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.
> > 
> > The only thing to watch there is that mmap isnt available on all platforms
> > (eg Linux 8086)
> 
> I know, but in that case we could just malloc() a memory section, and read
> the file into it. Of course neither would be good alternatives if you
> store fonts in a format that require processing when you read it in, but
> the format BOGL uses now is easy to modify so that isn't necessary.
> 
> Regards,
> Vidar
> 
> 

> Geez, combining Mozilla and nanoX sounds like David and Goliath,
> or is it Godzilla and humans... ;-)

there's a mailing list/newsgroup dedicaced at reducing mozilla's size down so 
they're going to be useable in typical doze CE PDA (of course with any OS
ported to these machine),will get the url in a moment.

Alain Toussaint

Does anybody think it would be interesting if I pushed development of the nano-Win
api forward so that the Windows sources of Mozilla could be used with nanogui?  Or
is it far simpler to use the *nix version that uses X?

Greg

On Wednesday, May 12, 1999 10:01 AM, Alain Toussaint ####@####.#### wrote:
> > Geez, combining Mozilla and nanoX sounds like David and Goliath,
> > or is it Godzilla and humans... ;-)
> 
> there's a mailing list/newsgroup dedicaced at reducing mozilla's size down so 
> they're going to be useable in typical doze CE PDA (of course with any OS
> ported to these machine),will get the url in a moment.
> 
> Alain Toussaint
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>