Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site Shasta.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!glacier!Shasta!gus
From: gus@Shasta.ARPA
Newsgroups: net.micro.mac
Subject: Re: bug in FillPoly?
Message-ID: <21@Shasta.ARPA>
Date: Fri, 31-Jan-86 13:39:24 EST
Article-I.D.: Shasta.21
Posted: Fri Jan 31 13:39:24 1986
Date-Received: Sat, 1-Feb-86 21:26:33 EST
References: <664@harvard.UUCP>
Organization: Stanford University
Lines: 31

> 
> 	We have found what seems to be a quickdraw bug.  The code that
> triggers it is as follows (in C):
> 
> 	PolyHandle ph;
> 
> 	ph = OpenPoly();
> 	MoveTo(2134,638);
> 	LineTo(-5000,-4954);
> 	LineTo(5000,2051);
> 	LineTo(1646,882);
> 	ClosePoly();
> 	FillPoly(ph,white);
> 
> 
> 	This causes a violent system crash, with all sorts of 
> screen-shaking and sound effects.  ...

This sounds like the same sor of bug that I reported on a year ago and
has to do with the way large polygons are handles. My experiment was to
create larger and larger polygons by selecting an increasing number of
random points on the screen. The system bombed after about 30. While yours
only sas four points, the X,Y coordinates are completely unresonable.
While I havn't looked into the exact algorithm, I saw a lot of mucking
around with raster lists and regions. Th "classic" polygon fill algorithm
requires that you keep a compete list of raster coordinates and then sort
the list. This chews up memory to no end. 

I have not run any of these experiments on the new 128K ROMs, however.

							Gus Fernandez