Re: fbcon slowness [was NTP on 2.4.2?]

[Pavel Machek <pavel@suse.cz>]

Hi!

> > >Are you using fbcon? If so, and if it goes away after starting X, then it
> > >is the "fbcon kills interrupt latency" problem.
> > 
> > Ug!!! This is getting bad. Give me some time. I plan on releasing a new
> > vesafb using MMX to help speed up the drawing routines. It will help alot
> > with the latency issues. I also know using ARM assembly we can greatly
> > reduce the latency issues.
> 
> On console speedups: back in the old days, scrolling a subregion of the
> text console to be _really_ slow on some machines.  I am talking about
> text mode now, not framebuffer mode.  On some cards, text mode is
> actually very very slow and the framebuffer is faster.  It took *2
> seconds* to scroll a 50 lines of text 50 times on my 200MHz PPro system
> 4 years ago.  So less "back one screen" took 2 seconds.  And Emacs uses
> "scroll region by N lines" a lot.  In those days, "N lines" scrolls
> actually did N x 1 line scrolls, so text mode was really a burden on
> that machine.  I took to using X, with a single screen size xterm to
> present the illusion of console mode.
> 
> Well, nowadays on my laptop we have the joy of the framebuffer console.
> Nice penguin aside, it means I get a console on the full screen area.
> 
> But it is nearly as slow at scrolling as my old 200MHz PPro.

You have same toshiba satellite as me, right?

> Probably the lack of hardware area copies has something to do with
> this.  However, who isn't familiar with xterm "jump scroll" mode?
> That's nice and fast.
> 
> Could such a thing be implemented in the console driver?

I believe so. It would be simple: if there's too much activit, defer
framebuffer updates and only update in-memory copy. Sync from time to
time. I'd certainly like to see that.
								Pavel
-- 
The best software in life is free (not shareware)!		Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+