On Thu, 2003-02-27 at 14:42, Keith Packard wrote:
> > Granted, if you have hardware alpha blits that will be the fastest way to
> > do this. But if you don't have hardware alpha blits (and lots of cards
> > supported by XFree86 do not), you can still speed up anti-aliased text
> > quite a lot by using a 4 or 8 level scheme using multiple mono bitmaps.
>
> I suppose, but it wouldn't be compatible with the Render semantics. If
> I'd heard users complaining about text performance, I'd be more interested.
> Plus, the number of users with cards that can't support image compositing
> is rapidly declining; essentially any card that has even the smallest
> amount of acceleration for 3D graphics can accelerate Render.
Actually, we get a fair number of complaints about AA-gnome-terminal
speed, though some of that is just bugs in gnome-terminal that have
now been fixed.
But the software side could be made many times faster; especially
considering that gnome-terminal is almost always
text-on-constant background. And text-on-constant background should
possible to make as fast as PCI/AGP write bandwidth. (*)
(A lot slower than hardware compositing, but not remotely slow.)
Regards,
Owen
(*) There are two levels of server-side optimization you can do
for text-on-constant-background.
a) If you keep track of the fact that a Pixmap is constant
color, you can migrate from video ram to system ram
about 100x faster than actually copying the data.
Compositing system-ram-to-system-ram is fast.
b) If you keep track of the fact that a Pixmap is constant
color, you could have special-cased compositing routines
that avoid even having to read the destination image.
But this involves yet more paths in the compositing
code. (Yuck.) This one is also harder to properly handle
for the multiple-write case. You'd probably have to
keep track of a constant-color _region_.
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
