[plug] NVidia drivers and RENDER acceleration
Cameron Patrick
cameron at patrick.wattle.id.au
Fri Oct 17 10:16:34 WST 2003
On Fri, Oct 17, 2003 at 09:51:30AM +0800, Craig Ringer wrote:
| >True that most people don't want
| >their compilation to go slower, though, and it's bad if a terminal
| >actually displays slowly because it's consuming large amounts of CPU
| >time.
|
| And that's what's happening here. It's working so hard, on my 1.5GHz
| Athlon, to DISPLAY TEXT that the stdout buffer fills up and the compile
| job pauses blocking on output until the terminal gets around to
| displaying some more text.
Yes. konsole --noxft is just so much faster than the AA version it's
not funny. gnome-terminal is even slower than konsole, in my subjective
experience. But there's nothing important (to me, anyway) that konsole
or gnome-terminal does that xterm doesn't, so I've been using a plain
xterm lately.
Incidentally, even xterm with large TrueType fonts can take a while to
redraw the screen. e.g. a full-screen xterm with a 20px font gives
lovely clear text - roughly comparable in size to the 80x25 console, but
a lot nicer on the eyes. It takes several hundred milliseconds to
redraw the screen when hitting page-down or flicking between one screen
session and another. Using bitmap fonts, this is essentially
instantaneous.
| Additionally, I'm not always working on modern hardware. Accelerated
| RENDER on the s3 driver in particular would make it practical to use
| XFT2 and RENDER on a lot of older hardware. As we use s3 based P133
| xterms at work, you can imagine the interest in accelerated RENDER - I
| have found it to be the single biggest issue with application
| responsiveness on the terminals.
Do S3 cards even have appropriate hardware that /can/ accelerate render?
| Having used X on other platforms where it's integrated into the OS and
| uses the system framebuffer, I've been very impressed at the instant VT
| switch you get. It'd be handy - nothing more - to see this with XFree86.
Out of curiosity, does using XFree with the framebuffer driver give you
this kind of speed? (Admittedly the framebuffer driver is yucky for
just about everything else so you wouldn't want to use it in general.)
This isn't something that I really care about as once I'm in X, I tend
to stay, and can put up with waiting a second on the rare occassions
that I /do/ flick between VTs.
| As for small delays mattering - application start times are an excellent
| example of this. Click ... wait .... wait .... wait ... there we go. A
| right pain for an app that's limited function and you only /use/ for a
| second anyway - say, a mixer panel.
One (of the few) thing(s) that I noticed after upgrading from an 800MHz
machine to an Athlon 2600 was Mozilla starts in well under a second.
The OO.o quickstarter can achieve the same for OpenOffice - although it
cheats by keeping the bloody thing in memory all the time - and most KDE
apps launch quickly when you're using the KDE desktop environment. (The
same can be achieved without running KDE all the time, BTW, by sticking
kdeinit &
in your .xsession)
Cameron.
_______________________________________________
plug mailing list
plug at plug.linux.org.au
http://mail.plug.linux.org.au/cgi-bin/mailman/listinfo/plug
More information about the plug
mailing list