Konsole scrolling

[Karl Vogel]

On 20 Feb 2003, you wrote in kde.kde-optimize:

> Which scroll-speed are we interested in? Scrollbar scrolling or
> scrolling caused by issuing "find /"?

The scrollbar kind.. dragging the scrollbar soaks up all CPU time and is 
really laggy.

> You can improve the latter by fiddling with the refresh rate.
> Refreshes are slightly delayed and forced after every N bytes/packets
> of data. Not exactly, but something like that. See TEmulation.cpp and
> how showBulk() gets called. 

Yups.. I understand how the bulk operation works. It's this that makes the 
scrolling of shell output acceptable (delaying updates with the bulk timer 
or until a NewLine is seen). -- correct me if I'm wrong

But even for the NewLine case, using a scroll() would be faster and more 
importantly, less of a cpuhog.

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)

So if we can somehow make the interaction between TEmulation <-> TEWidget a 
bit smarter, then the cpu hogging would be resolved.

At the moment TEmulation just sets the new history position when the 
scrollbar is moved and then instructs TEWidget to do a diff screen update 
(which changes every line). Instead it could pass a scroll offset and 
UpdateLines(ybegin, yend) to TEWidget (or something like this).

> It's important that some updates happen rather fast, e.g. when you
> move your cursor due to the keyboard repeat it looks really bad if it
> only updates twice a second or so :)

You can get away with that if you tell people you are using a VNC 
connection :)