Subject: Re: xterm scrolling speed - scheduling weirdness in 2.6 ?!
From: Soeren Sonnenburg <kernel@nn7.de>
To: azarah@nosferatu.za.org
Cc: Con Kolivas <kernel@kolivas.org>, Willy Tarreau <willy@w.ods.org>,
       Mark Hahn <hahn@physics.mcmaster.ca>,
       Linux Kernel Mailing Lists <linux-kernel@vger.kernel.org>,
       gillb4@telusplanet.net
In-Reply-To: <1073214820.6075.254.camel@nosferatu.lan>
References: <Pine.LNX.4.44.0401031439060.24942-100000@coffee.psychology.mcmaster.ca>
	 <200401041242.47410.kernel@kolivas.org>
	 <1073203762.9851.394.camel@localhost>
	 <200401041949.27408.kernel@kolivas.org>
	 <1073214820.6075.254.camel@nosferatu.lan>
Content-Type: text/plain
Message-Id: <1073215450.3239.22.camel@localhost>
Mime-Version: 1.0
Date: Sun, 04 Jan 2004 12:24:11 +0100
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1720
Lines: 40

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/