Konsole scrolling

[Justin Hibbits]

On Fri, Feb 21, 2003 at 02:33:06PM +0100, Karl Vogel wrote:
> On 21 Feb 2003, you wrote in kde.kde-optimize:
> 
> > On Friday 21 February 2003 12:24, Karl Vogel wrote:
> >> 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.
> > 
> > But I think this is for a large part because konsole (from KDE 3.1)
> > tries to paint as often as possible, my patch schedules repaints more
> > cleverly in this case, it makes it more likely that a repaint begins
> > directly after you stop scrolling which reduces the laggy feeling.
> 
> I think I didn't explain the lag part properly. The effect is that the 
> display has a hard time of keeping up to date with my scrollbar movement. 
> It looks like it is always a few cycles behind.
> 
> ie. when moving the scrollbar up as fast as I can, my mouse pointer moves 
> more rapidly than the actual scrollbar widget. So the scrollbar + konsole 
> display follow a few cycles behind to my actual mouse pointer.
> This is probably because repainting the scrollbar widget + TEWidget takes a 
> long time, so with each update, it stalls.
> 
> Maybe a solution would be to be able to interrupt the update when a new 
> scrollbar value change is emitted?! (maybe add a scrollbar value check in 
> the update loop in TEWidget?)
> 
> 
> (hmm it's hard explaining these kind of things..)

Hmm, isn't a scrollbar change signal emitted whenever the scrollbar changes?
Why not queue the changes, so that only after X cycles/milliseconds/interval
it repaints.  This way, you either move the scrollbar slowly, or you move it to
appr. where you want it, and fine-tune when you're sure. This should ease CPU a
little, as repaints wouldn't be at every move.  Or is this what your patch does
Waldo? (Haven't looked at it, or much of the KDE source at all to tell you the
truth).

-Justin

-- 
Registered Linux user 260206