bdc@world.std.com said:
> We don't have a lot of spare processing power laying around to deal
> with inefficiencies.  Based on the above, it seems that scrolling is
> the greater of the two issues to be addressed.

It was clearly for the i386. From what I've heart, indirect jumps
are extremely expensive on the vax, so the weights might be a bit
different.
The way character output works now is:

for each character in the incoming string:
	if printable && (no control processing)
		lookup font index in table
		indirectly call driver output function:
			get font data and print
	else
		do control processing

Alternatively, one could:

for each character in the incoming string:
	if printable && (no control processing)
		lookup font index in table
		if (room in output buffer)
			put index into output buffer
			continue
		indirectly call driver output function:
			for each index in buffer
				get font data and print
		put index into output buffer
	else
		if (something in output buffer)
			/* flush output buffer */
			indirectly call driver output function:
				for each index in buffer
					get font data and print
		do control processing
if (something in output buffer)
	/* flush output buffer */
	indirectly call driver output function:
		for each index in buffer
			get font data and print


The latter does save a number of indirect calls to the driver's
output function, but this is paid with incleased complexity and
all the overhead for the management of the "output buffer" plus
the decicions to flush it in the right moment.
I'd say: Unless there are good reasons to do so, this is not worth
the effort.
Perhaps someone has an idea for another scheme which is more
effective...

> Is there anything which can be done to optimize scrolling
> in a machine independent way?

The scrolling itself is highly hardware dependant. Usually there
is a register which determines the beginning of the visible area
in the framebuffer or so. The "rcons" code does not support this
well - that's one of the reasons I'd rather not use it in the
wscons environment.
What I did to make it easier to implement such an acceleration
is that I changed the semantics of the wsdisplay_emulops->copyrows
vector to something like "moverows". No terminal emulation relies
on the rows which were copied "away". (should be documented...)

best regards
Matthias