View Single Post
Old 07-26-06, 04:28 AM   #115
d13f00l
Registered User
 
Join Date: Apr 2005
Posts: 197
Default Re: Slow AA text rendering in KDE

Quote:
Originally Posted by Linuxhippy
All apps are affected which draw glyphs via subpixel-aa to native surfaces (screen, pixmaps). No matter wether you use gtk, xlib or qt. About 4 months ago I wrote microbenchmarks.
But however since I assume you can't code (really well) ... you just have to trust me.
What does kedit draw to? It's totally fine, while kwrite is not.

Are the microbenchmarks you're referring to those QT programs that drew a string like 10,000 times and timed how long it took, or are you talking about something else? Also, didn't you say once that Java rendered subpixel hinted text much faster than QT or GTK?

Also, you have a A64 3400? I don't believe that's a dual core chip, as in, you only have one processor, while a multi-core Xeon computer would have several.

If an application used 100% cpu time, the person on the Xeon system would barely notice because their other CPUs are free, while your A64 would slow to a crawl.

You don't have an A64 X2, right?

An a64 in this case is not comparable to a Xeon system, the Xeon system will not be affected.


I'm not that familiar with QT or GTK, or X in general.

Naturally, subpixel hinted text rendering is going to be MUCH slower than any other kind of text rendering no matter how you look at it. My point is that only some KDE programs are actually slowed down to the point of unusability. If I drag a screen full of text around in kedit, my CPU usage might be at 40-50%, but that's fine. KWrite it will be at 100%.

What do you expect Nvidia to do? Their Xrender implementation isn't the best, but I don't think there's a performance-crushing bug in particular that's causing this. It happens with other cards, and it happens also on my Geforce 4 MX 440.

What are you suggesting? There doesn't seem to be any driver regressions anywhere. It works good in older drivers because it was brokenly HW accelerated, and now it's fixed and slowly done in software.

I could write an SDL program that does subpixel hinting in software if I _REALLY_ wanted, and I could make it run at several thousand frames a second by being efficient in my code.



Do you have a test app written in with XLib/XFT? That would be interesting to see if it was still slow.....maybe I will code one up tomorrow night. It can't be too hard...

Last edited by d13f00l; 07-26-06 at 04:42 AM.
d13f00l is offline   Reply With Quote