FYI, in case some of you don't follow port-i386.

Those of you who have opinions on this better voice them now...

Gunnar

--
Gunnar Helliesen   | Bergen IT Consult AS  | NetBSD/VAX on a uVAX II
Systems Consultant | Bergen, Norway        | '86 Jaguar Sovereign 4.2
gunnar@bitcon.no   | http://www.bitcon.no/ | '73 Mercedes 280 (240D) 

-----Original Message-----
From: drochner@zel459.zel.kfa-juelich.de
[mailto:drochner@zel459.zel.kfa-juelich.de] 
Sent: Thursday, November 12, 1998 9:00 PM
To: perry@piermont.com
Cc: M.Drochner@fz-juelich.de; port-i386; tech-install;
drochner@zel459.zel.kfa-juelich.de
Subject: Re: 2 Problems 


perry@piermont.com said:
> Charles noted to me a while back that wscons was slow because it only
> processes one character at a time.

I remember a mail from Charles where he blamed slowness to two things:
-one character at a time, as you say
-scrolling by copying
Some profiling showed that the scrolling did indeed use up a significant
fraction of CPU time (not top-ranking, still less than bz^H^Hmemset,
but worth optimizing). Character output was much less.
So I changed the scrolling to use offset registers on VGA.
The reason that the character output is done this way is that
the terminal emulation module interprets the incoming (8-bit)
characters and spits out indices (32-bit) into a potentially larger
character set, keeping state about charset switching control sequences.
It has to touch every incoming character anyway, and even if it did
try to cache a row it would have to transform each character into
the 32-bit font index and put it into a separately allocated array.
I'm not convinced this is worth the effort.

> Any idea if we can fix that problem? 

For me, this is not a problem. As long as the vax people don't
complain...

best regards
Matthias