[Konsole-devel] Re: Konsole scrolling

[Waldo Bastian]

On Thursday 20 February 2003 12:45, Karl Vogel wrote:
> 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.

Hm.

> > 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.

That depends, if between two updates an entire screen has scrolled by, there 
is no gain.

> 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 then you are most likely 
scrolling more than one page, so you will not gain anything.

There is also c) You scroll a lot and do updates for every few lines. That's 
stupid :) but might very well be what konsole is doing.

The following patch makes some changes to the bulk algorithm and uses it for 
scrollbar related updates as well. It guarantees a refresh rate between 100Hz 
and 20Hz, assuming your CPU is fast enough for the latter :-}

Does this help? bitblt-based scrolling could still be done on top of this, but 
I'm afraid it will be really hairy to get it right. The current approach with 
the images was specifically choosen to get rid of the hairy bits :)

Cheers,
Waldo
-- 
bastian at kde.org -=|[ SuSE, The Linux Desktop Experts ]|=- bastian at suse.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: konsole_scroll.diff
Type: text/x-diff
Size: 4010 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/konsole-devel/attachments/20030220/35b450a8/attachment.bin>