Bill Sommerfeld wrote:
> 
> > That's a good idea, but unfortunately there's no way to predict more
> > scrolling will happen after several lines scrolled up.
> 
> Look at how xterm does jump scroll -- if a single "chunk" of output
> (probably from a single write() call) contains multiple newlines, it
> scrolls the screen by that many lines in one chunk and then draws in
> the four new lines of text.  On an N line screen, this allows
> scrolling by K lines all at once take (N-K) units of work rather than
> K*(N-1).
> 
> Last time I looked at this (some months ago), I came to the conclusion
> that some of the wscons internals need to be tweaked to allow for
> lookahead in the output stream..

This may need some technical description: In both the original VGA driver 
and the new raster display driver, until the display offset (dispoffset) 
reaches to the limit (maxoffset), no data is actually copied while 
scrolling is taking place. Instead, the start address of the region 
currently displayed on the screen which a couple of video registers are 
pointing to increases. Let's look at the following figure:

+----------------------+ (Start of the display memory)
|(past messages)       |
|		       |
|$ ls -l               | <--. 
|Total 36              |    |
|drwxrwxr-x            |    |
|                      |    |
.                      .    +--- Actually seen on the screen 
.                      .    |    (25 lines)
|                      |    |
|drwxrwxr-x            | <--'
|$                     |   
|                      | <--- After scrolling, dispoffset is pointing
|                      |      to the address of the next line.
|                      |      
|                      |
+----------------------+ (End of the display memory) <--- maxoffset

In theory, most of the time scrolling is as fast as in text mode. However,
the problem arises when dispoffset reaches to the limit, maxoffset. Then 
every bit of the memory to be displayed should be copied to the start 
address of the display memory. With text mode, this requires merely about 
4kB (80 * 25 * 2) of data copying, but with graphics mode, much larger 
80 * 400 bytes (32kB) of data copying, which makes the system a bit 
slower and less responsive. 

Therefore, the solution can be largely in two ways:

	- to have larger linear framebuffer
	- to improve memory copy performance

Unfortunately, neither seems to be possible with standard VGA. :(

Jun-Young

--
Bang Jun-Young <bjy@mogua.org>