AntiAliased text on X [was code bloat]

[Adam Jackson]

On Monday 01 November 2004 18:38, Kendall Bennett wrote:
> Lee Revell <rlrevell at joe-job.com> wrote:
> IMHO that is mostly because X.org and all projects above it do anti-
> aliasing via RENDER, which requires hardware alpha blending. Doing alpha
> blending in software is really slow. I am pretty sure that Windows does
> cheap anti-aliased fonts without needing hardware ALPHA blending by
> breaking down the glyph into multiple layers of shaded pixels. If you
> have say 8 levels of shading, then you decompose each glyph into 7
> different mono bitmaps, each one representing the pixels that need to be
> drawn in each of the shaded colors. Then you draw them over the top of
> each other with transparency as mono bitmaps, and voila! Anit-aliased
> text.
>
> We do that in our SciTech MGL library (I forget exactly how many levels
> we use in the MGL) and FreeType has always been able to generate these
> types of multi-layer glyphs. For machines with hardware alpha blending
> (and drivers that support it ;-), doing it that way is probably fast
> enough and looks good. But for slower hardware or older hardware, this
> can be done very fast using the existing mono blit hardware used for
> regular text. Sure it would be 7x slower than regular text, but *WAY*
> faster than any blending done in software to the framebuffer.

Interesting.  I'm curious whether this would be faster in the shadowfb case.  
Software Render is slow largely because framebuffer reads are slow.  I can 
get nearly-acceptable Composite performance on old nasty PCI cards with no 
Render accel just by turning off XAA and turning on shadowfb.

KAA is much closer to a shadowfb model than XAA.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20041101/1c2c9afc/attachment.pgp>