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!