Konsole scrolling

[Karl Vogel]

I have been looking into the (slow) scrolling speed of Konsole, partly due =
to
a bug report (Bug #53983) and partly since I also noticed it on my machine

:-)

=46rom a quick glance at the source I understand that this is currently
implemented like this:

=2D TEScreen
this class holds the character screen + attributes (see TECommon.h header, =
in
short it holds: character, foreground color, background color, rendition)

=2D TEmulation (TEmuVt102)
handles emulating the escape codes and uses TEScreen to keep the screenbuff=
er
data (plain ascii chars, no graphics image yet).

=2D TEWidget
this class is used to do the actual drawing on screen.


When the user moves the scrollbar, TEWidget emits a signal which is process=
ed
by TEmulation.

TEmulation sets the new cursor position via TEScreen and then asks TEScreen
for the 'image' of the screen (NOTE: the variable choice here is confusing =
as
'image' here refers to the char screen+attributes buffer, NOT a graphics
image). This is done with TEScreen->getCookedImage().

Then TEmulation calls TEWidget->setImage() which does the actual screen
painting. The problem here is that it processes the entire screen buffer, ie
it looks for differences since the previous screen and if there is a diff on
a line, it calls drawAttrStr() to draw that line/row.

TEWidget has no knowledge of scrolling, it can only paint a char+attrib
 buffer to screen (optimized a bit by only updating differences).

Now.. when one drags the scrollbar less than a page, this means that it has
 to update the entire screen, row by row, redrawing each line (as each row
 has changed) instead of just Scrolling the Widget up/down and using
 drawAttrStr() to draw the new lines.

So the solution would be to somehow use the QT widget scroll, which is
internally a bitblt (so VERY fast), and then draw the new lines.
The problem ofcourse is.. where do we stick this without breaking the
abstraction level.