Re: xterm scrolling speed - scheduling weirdness in 2.6 ?!

[Soeren Sonnenburg <kernel@nn7.de>]

On Sun, 2004-01-04 at 12:13, Martin Schlemmer wrote:
> On Sun, 2004-01-04 at 10:49, Con Kolivas wrote:
> 
> > > I added a fprintf(stderr, "%d\n", amount); to that code and indeed
> > > amount was *always* 1 no matter what I did (it even was 1 when the
> > > (dmesg/...) output came in fast). And jump scrolling would take place if
> > > amount > 59 in my case... can this still be not a schedulers issue ?
> > >
> > 
> > > Looking at that how can it not be a scheduling problem ....
> > 
> > Scheduling problem, yes; of a sort.
> > 
> > Solution by altering the scheduler, no. 
> > 
> > My guess is that turning the xterm graphic candy up or down will change the 
> > balance. Trying to be both gui intensive and a console is where it's 
> > happening. On some hardware you are falling on both sides of the fence with 
> > 2.6 where previously you would be on one side.
> > 
> 
> So its Ok for 'eye candy' to 'lag', but xmms should not skip?  Anyhow,
> its xterm that he have issues with, not gnome-terminal or such with
> transparency.  I smell something ...

I would not call it 'lag' if an ls of /usr/bin takes 20 secs vs 1 sec
before... I mean the scroll speed limits e.g. the compile speed...

Well I now tried xterm, gnome-terminal (gtk2), multi-gnome-terminal
(gtk1), xvt, aterm, wterm, Eterm, and yes they are all (except for
Eterm) plain text on solid background - so no eye candy. Interestingly
Eterm, wterm and aterm seem to not be affected by that issue.

Soeren