AntiAliased text on X [was code bloat]

[Kendall Bennett]

Owen Taylor <otaylor at redhat.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.
> 
> That way is likely blazingly fast. 

Yes.

> But it only works for solid color backgrounds - and for solid
> colored backgrounds, there's a different optimization that would
> already make things a lot faster and preserve full 8-bit alpha
> channels, and even subpixel antialiasing: just don't fetch the
> underlying bits from the framebuffer  - blending solid color over
> solid color in software and writing to the frame buffer is going to
> give you pretty close to the magic million glyphs / second on
> hardware from the last few years. 

Yes, that is a very good optimisation and something worth considering.

However you can still use the multi-level approach with non-solid color 
backgrounds. Basically if you have 7 levels of bitmaps to draw, you only 
have to draw with blending the pixels in the lower 6 levels. The top 
level is always opaque so you draw that as fast as possible in hardware. 
Since the lower 6 levels of the glyph contains probably less than 10% of 
the total pixels to be drawn, even though the blending of those pixels is 
still slow, the entire operation is significantly faster than drawing an 
entire AA glyph in software. Mostly because modern hardware can draw 
glyphs from system memory bitmaps, very, very fast. So the only slow down 
is the blending of the small number of pixels around the edges.

Still it would be interesting to try both approachs and see which one 
turns out to be faster.  A useful optimations for your approach would be 
to make sure the blender that is blending the AA bitmap is taking a fast 
path for solid pixels (that would work even for blending to the 
framebuffer also).

> I did some experiments with client side tracking of solid areas a
> while ago. Implementing the same algorithms on the server shouldn't
> be very hard. (Just catch a full-pixmap XDrawRectangle, initialize
> to "all solid" with the paint color, then subtract out from there
> as the client draws. That handles normal toolkit usage.) 

Sounds good to me ;-)

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~