View Single Post
Old 07-22-06, 12:34 AM   #92
d13f00l
Registered User
 
Join Date: Apr 2005
Posts: 197
Default Re: Slow AA text rendering in KDE

Quote:
Originally Posted by Linuxhippy
I just wanted to warm-up this topic ... since I guess I've found an explanation why GTK performs much better than QT based applications.

GTK uses a lot of very short-living pixmaps which are never moved to vram (so, almost all rendering in GTK applications is done in software and you GPU stays unused).
And because the most expensive part of software rendering to hw-accalerated surfaces is vram-readback and upload its a lot faster since the desination surface is already in RAM.
After drawing a singly large ram->vram transport happens instead of many small ones, which again should be faster.

So GTK has faster subipxel-rendering more or less through an accident, but looses almost all possible hw-accalerated drawing. I hope both problems will be addressed in future.

lg Clemens
Subpixel AA currently is done in software, anyway. There is no acceleration. If KDE applications are doing software graphical operations in video ram, that would explain the issue. It's a waste of bandwidth to be moving things from video ram to system ram when there's no acceleration being done in VRAM anyway. I wouldn't call it an accident, it's more like a blessing since subpixel font aa is pretty complicated to accelerate anyway, maybe GTK developers realize this and implemented it as such.

There's something wrong with Nvdia's render acceleration, probably, as well. That's going to be worked on more, I'm sure.

I've developed a strong distaste for QT apps over the past 6 months, UI inconsistencies and issues with font AA. I switched to GTK and XFCE and I haven't looked back.
d13f00l is offline   Reply With Quote