nanogui: Thread: NanoX version 0.3 released

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

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

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

On Tue, 11 May 1999, Alex Holden wrote:

> On Tue, 11 May 1999, Vidar Hokstad wrote:
> > Yeah, I remember that too.. There's still a lot of bloat there, IMHO, but
> > it's been steadily dropping in size. Also, most of the bloat is in the
> > Mozilla GUI code, it seems, not in the rendering engine. The rendering
> > engine is actually pretty nice now :)
> 
> Any idea why there is a noticable delay between moving the mouse pointer
> over a button, and the button becoming highlighted? GTK+ doesn't do that,
> so they must have messed around with the event chain somehow, adding
> masses of processing into what should have been a pretty fast response
> chain. I don't see why they would have done that though...

I don't know exactly what it is, but the general sluggishness of the Linux
port is supposedly something with a known solution on the todo list, so I
expect it to be fixed soon.

If you do a "strace" on apprunner or viewer, you should see right away
that there's something funny going on :-)

Vidar Hokstad ####@####.####
Director of R&D, Screen Media AS

The multiple process access is a good point that I hadn't thought of.  Of course,
it would only happen if multple graphics servers were run, which I guess could happen.

On the int10 access, I'm writing that only for the ELKS port to get it off the ground
quickly, since that's the point of the BIOS: an unchanged api over differing hardware.

With nanoX v0.3, anybody can write any driver they choose, and nanoX will run with it...

BTW, direct hardware access still has the multiple process problem.

I would be very grateful if you or anyone else would like to donate some non-bios
direct access routines for some more modern graphics cards.  The problem is that
EGA cards only support 256 color with 320x200 thru a standard interface (BIOS)
or 16 color 640x480.  Nowadays, people want high resolution and high color.

Take a look at /usr/src/linux/drivers/video/atyfb.c (linux v2.2) or vesafb.c.  (BIOS).

It would be *really great* to tear out all that stuff into a nanoX driver!  Then I could
run nanoX standalone in 1024x768 mode!!

Greg

On Tuesday, May 11, 1999 9:49 AM, Eric J. Korpela ####@####.#### wrote:
> 
> >	o MSDOS driver support.  I wrote a 640x480x16 color driver in about 45 minutes.
> >NanoX now runs on DOS!  (OK, I did this only to see how portable nanoX
> >is, and the 
> >mouse driver still isn't written)  This still uses MSC graphics library.
> >I'll have the bios
> >int10 version driver done shortly, which will allow nanoX to run on
> >ELKS!  We should
> >have an ELKS version shortly...   BTW, the nanoX kernel is around 20k on DOS...
> 
> Does anyone else agree with me that direct int 10 access is a mistake?
> Wouldn't access through a device driver be a bit more unixy?  It would
> be able to prevent multiple processes from trying to access int 10 services.
> 
> Eric
> 
> 
> 

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

Greg

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.

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.

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.

Regards,
Vidar

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
> 

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 ;-) )

> Whatever is non-essential. The processing which GDK does should be in the
> GDK library, only the interface to the Nano-X server should be in the
> Nano-X server should be in the Nano-X library. The interface could be
> modified to make it easier to port GDK, but I don't want to force people
> to compile GDK in if they don't want it.

GDK wants routines like plot a pixel, draw a line, the same primitives everyone
else uses for 2D

> As the complete functional parts of GTK require a space of about 10meg (
> here Solaris, correct me please.), the libnano-GDK.so wouldn't be used on

You have something terribly wrong then. A full gtk based app is a few
hundred K including the shared libraries (ie RAM-cheap not FLASH-expensive)

Probably the smallest portable toolkit that has done good real work is 
FLtk

> 

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

Those are full library sizes for static libraries with symbols built with
X support and every X feature. 

Alan