Xref: utzoo comp.sys.mac:36090 comp.sys.mac.programmer:8155
Path: utzoo!utgpu!watmath!att!bellcore!rutgers!cs.utexas.edu!csd4.milw.wisc.edu!bionet!ames!claris!apple!apple.com!casseres
From: casseres@apple.com (David Casseres)
Newsgroups: comp.sys.mac,comp.sys.mac.programmer
Subject: Re: System 7.0 speculations: Hot Scoop?
Message-ID: <3412@internal.Apple.COM>
Date: 8 Aug 89 21:59:42 GMT
Sender: usenet@Apple.COM
Organization: Apple Computer, Inc.
Lines: 28
References:<587GDAU100@BGUVM> <26548@amdcad.AMD.COM> <24101@iuvax.cs.indiana.edu> <458@lloyd.camex.uucp> <3300@internal.Apple.COM> <24388@iuvax.cs.indiana.edu>

In article <24388@iuvax.cs.indiana.edu> truel@silver.bacs.indiana.edu 
(Robert Truel) writes:
> Anti-aliasing merely requires generating a bitmap in a larger (double) 
> resolution and then averaging some number of pixels (four) to
> determine the shade of gray to use.

I think the word "merely" is stretching it.  For one thing, as Amanda 
Walker points out you probably want more than two gray levels in between 
black and white.  It's going to involve significant processing and 
significant amounts of RAM.

> This intermediate step can of course
> be skipped when computing bitmaps from curves (the averaging being done
> in the process of computing the curves), but it seems that this would be
> a small amount of cpu time compare to calculating b-splines (or bezier 
> curves) and grid shifting.

Calculating the curves is not the time-consuming part, as I understand it; 
filling the curves is, and boundary-testing is the hard part of filling 
algorithms.  If you do multi-level gray-scaling at the boundaries, the 
worst part of the problem is suddenly much more complex.  None of this 
stuff is impossible; but if you have to recreate a multi-level pixmap each 
time you draw a character (with sub-pixel positioning), and you don't want 
performance to go down the drain, it's a hard problem.

David Casseres

Exclaimer:  Hey!