Re: Speeding up screen output for dialog

becka@sunserver1.rz.uni-duesseldorf.de
Wed, 4 Sep 1996 21:07:53 +0100 (MET DST)

> > I've been wondering why some dialog-based applications
> > (e.g. menuconfig) take so long even on a P90 to draw the screen. So I
> > made some investigations with strace. I found that ncurses writes to
> > the screen in rather large blocks of bytes, but these get broken up
> > in write_chan() in n_tty.c into single byte writes to the console,
> > which is inefficient (I assume that setting the cursor after each
> > write is the most time-consuming part). So I came up with a hack:
> > Instead of calling opost() for each byte, I wrote a new function
> > opost_block() that examines the buffer and returns the number of
> > bytes that can be directly written. These are then passed to
> > con_write() instead of put_char().
> >
> > You've defintiely identified a real problem in the slowness of the
> > console. However, the solution isn't really the best one, as it
> > requires that characters be read an extra time --- once in opost_block,
> > and once in the driver's write routine. When you consider that most
> > interrupt driven devices have to buffer characters themselves (what BSD
> > calls "pseudo-dma"), that means that there will be three copies, and
> > that's non-optimal.

There is a far better solution. The console protocols have been designed
for serial lines with "inband-signalling" of events other than characters.
This is what we know as "escape-sequences". Even if there is a workaround
for the particular problem shown here, it is still slow compared to what
most other systems do.

The problem shows up for me particularly for color-apps. These add another
layer of inefficiency by sending lots of "change-color" commands via
escape sequences.

The solution is simple. Give ncurses access to display memory. ncurses can
detect the display-type TERM=linux and try to use this feature when on
console.

You will now probably tell me "NO ! NO ! The binaries would have to be suid
root to map the mem !" and you are right for now.
But there is something lurking out there to overcome this problem.

It is called GGI.

It is supposed to provide Linux with a "general graphics interface" that will
allow graphics software (and text as a side-effect) to run independent of
the hardware and architecture below. We currently achieve over 40MB/sec
transfer-rate using an old 486/66 with a PCI SPEA Mercury S3-964 based
video card.

> I have written a patch for this which implements put_char() and
> flush_chars() for the console. It seems to work quite well. A
> test program that writes 4000 byte blocks at a time, 1000 times,
> takes about 9.5 seconds in my patched kernel and 55.8 in the
> old kernel.
With GGI this takes about 0.1sec (assuming access to textmode is not
slower than graphics mode, but even then it will probably not exceed
1.0 sec.

> The only problem now is that I just grabbed 2.0.17 to
> make my patches against that and now my X server won't start (and
> of course I have it going straight to xdm from inittab so I get
> stuck).
Sad ... since GGI I never got stuck again (except due to programming-
errors in ggi that were my own fault ... kernel-hacking is risky ;-).

GGI provides a 100% working SAK (secure attention key) to me.

I can even kill off X cleanly and GGI will return me to a textmode
login-prompt. Only a really hard kernel crash can force me to use
the reset button now.

I apologize, if this seems quite a bit offensive, but we (the GGI
people) have received not much positive responses from some of the
kernel-gurus, and I wanted to show that GGI isn't just another
SVGAlib, but has potentials that go far beyond a simple "graphics-
driver".

For those that got interested now : visit my homepage to see some outdated
concepts of GGIs predecessor scrdrv or even better have a look at the GGI
project homepage at http://synergy.caltech.edu/~ggi/.

We are currently working on a "public preview release", that requires only
a very slight kernel-patch and shows many (but not all, due to the
limited patch) features that final GGI will have.

The release will be in about a month, when we have eliminated some problems
with generic VGA support, so that most people out there can try it out.

TNX 4 your time,

Andy

-- 
==============================================================================
Andreas Beck              |  Email :  <becka@sunserver1.rz.uni-duesseldorf.de>
===  World-Wide-Web URL :  http://sunserver1.rz.uni-duesseldorf.de/~becka  ===
==============================================================================