Konsole scrolling

[Karl Vogel]

>> The problem is that the knowledge about how to update the screen is
>> thrown away and instead an entire screen diff update is done, whereas
>> we KNOW only the last line really changed. (or in case of scrollbar
>> scrolling, we know which lines don't need repainting)
> 
> True. I doubt however that this will really gain you so much. You
> either a) scroll a little in which case you don't care much about the
> CPU, because it is only a small spike. Or b) you scroll a lot, but

One thing you are forgetting here is that not everybody uses a local X 
server! For XTerminals the difference between using a scroll and repainting 
the whole screen might make a huge difference in speed and network load. 


I tried my little test here on an LTSP client (Linux Terminal Server 
Project), which is a P1 166Mhz machine with an old S3Trio64 videocard, 
running XFree 4.2.99 in 1024x768x8 (only 1Mb video ram), no anti-aliasing. 
The machine is connected over 100Mbit to a P2 400Mhz 'server' -- so konsole 
runs on the P2. KDE is the stable 3.1 release.

Using konsole there is a considerable lag feeling as it can't keep up with 
the scrollbar movement. Trying the same with an xterm gives satisfactory 
performance.

I didn't measure the network load this induces.


I still feel the scroll() might be useful.. if I find the time, I might try   
and mock something up to test my theory.