Path: utzoo!attcan!uunet!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!kth.se!cyklop.nada.kth.se!news
From: d88-jwa@dront.nada.kth.se (Jon W{tte)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Mathematical problems with QuickDraw
Message-ID: <1990Oct20.233910.28991@nada.kth.se>
Date: 20 Oct 90 23:39:10 GMT
References: <1990Oct20.193947.16700@agate.berkeley.edu>
Organization: Royal Institute of Technology, Stockholm, Sweden
Lines: 64

In article <1990Oct20.193947.16700@agate.berkeley.edu> deadman@garnet.berkeley.edu (Ben Haller) writes:

>QuickDraw.  First, there's the abominable oval algorithm, which produces gaps
>in ovals that have one long axis and one short axis.  This makes is impossible

This ought to be fixed...

>  Next, there's the problem QuickDraw has with lines.  It chooses the pixels

>correct, put the "jog" in the middle of the line.  It doesn't, it puts it
>at one end, like:

This argument is also valid. How about some "fixed" math in there ?
(Pun intended)

>  QuickDraw has a strange habit of drawing extra pixels in its circles.  It
>often gives you circles like:

Well, actually they aren't extra. You have to have those "L-shaped"
corners to avoid making the circle a hyper-ellipsoid. (Or whatever
that translates into in English...)

>choose correctly all the time?  Bresenham's circle algorithm (and Pitteway's
>ellipse algorithm) choose in this fashion; they make better-looking ovals,
>*and* they're the fastest algorithms I know of.  Why doesn't QuickDraw use
>them?

Because they're patented. Simple when you think of it, no ? :-)

>  Let's see, what else...oh yes.  It chooses the pixels for a FillPolygon
>in such a way that you can have a "net" of polygons that, mathematically,
>share v{rtices and therefore should form a solid "sheet", but when
>QuickDraw draws them, pixels show through in gaps between the polygons.  I

This has bugged me as well. Should be fixable, but the "really good"
algorithms are, unfortunately, patented...

>  IMHO, the whole thing with QuickDraw using "pixel grid intersections"
>instead of pixel centers is ridiculous.  I don't see what it's supposed to
>solve, and it certainly causes some conceptual problems (all your rectangles
>must be one pixel larger than they seem like they should be, for example).

Here I disagree, the current model suits me JUST FINE ! And, think of
it: You want a rectangle 16 dots wide - just draw it from 20 to 36,
sizteen dots wide and 36 - 20 == 16. If you used pixel centers, you
would have to do it from 20 to 35, not very logical.

>I have never suffered from "endpoint paranoia" - it sounds to me like

Well, I have (but I've overcome it) I know of lots of experienced
programmers who still do.

>"SlowDraw" instead...

Try doing clipping to an arbitrary shape yourself. See you in 2010 ;-)

Now, if the patches for the faults that actually ARE faults don't
eat all of the memory I have left when INITs and hungry compilers
and debuggers and projects and TechNote stacks and comm programs have
taken their toll, I'll consider going religious...

							h+
h+@nada.kth.se
"Moof!(tm)"