matthews@harvard.UUCP (01/30/86)
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. We tried it in Aztec C's example program and in Macintosh Pascal, with identical effects. Substituting black for the pattern parameter and calling ErasePoly instead of FillPoly yielded the same result. Is this a known bug, and if so is there a known workaround? FillPoly is integral to the program we are developing, and so it very important for us to find out when we can count on it. Any and all help would be appreciated. Jim Matthews matthews@harvard.arpa Greg Kuperberg greg@harvard.arpa
olson@harvard.UUCP (Eric Olson) (01/31/86)
I noticed a similar bug in MacDraw 1.7 (3/18/85): Define any nonstandard polygon, and select fill=anything but clear. Result: System Bomb. I couldn't believe it at first, since it seems like an obvious thing to check before releasing software. But if its a bug in the ROM, maybe they figured "We'll fix it with a system patch later" and never did. -Eric.
gus@Shasta.ARPA (01/31/86)
> > 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
tim@ism780c.UUCP (Tim Smith) (02/04/86)
In article <664@harvard.UUCP> matthews@harvard.UUCP (Jim Matthews) writes: > > 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); > > [ describes violent system crash ] I experimented with triangles this weekend. The triangle with vertices at ( 50, 50 ), ( 150*n + 50, 150*n + 50 ), ( 150*n + 50, 50 ) crashed with an out-of-memory bomb when n was 100, but was ok at n=10. There is no explanation for this in the pre-final editions of IM. However, the final edition of IM says the following, on page I-191: Graphic Operations on Polygons ------------------------------ Four of the operations described here - PaintPoly, ErasePoly, InvertPoly, and FillPoly - temporarily convert the polygon into a region to perform their operations. The amount of memory required for this temporary region may be far greater than the amount required by the polygon alone. You can estimate the size of this region by scaling down the polygon with MapPoly, converting it into a region, checking the region's size with the Memory Manager function GetHandleSize, and multiplying that value by the factor by which you scaled down the polygon. Warning: If any horizontal or vertical line drawn through the polygon would intersect the polygon's outlie more than 50 times, the results of these operations are undefined The violent crash you are getting sounds like a bug, but there may not be enough memory to do what you want, even if you get around that bug. You might have to split your large polygon into several smaller polygons and fill them one by one. Does anyone know what property of the polygon determines the size of the region made from it? Is it area? -- Tim Smith sdcrdcf!ism780c!tim || ima!ism780!tim || ihnp4!cithep!tim
bhyde@inmet.UUCP (02/06/86)
Regions are encoded in bands, each band is a horz. strip across the "screen." A band consists has no changes in the vertical direction, i.e. it could be drawn with a set of rectangles each one the hieght of the band. If you draw a diagional or curved line then region will consist of a band for every line. One way to approach the problems this introduces is to "clip" the polygon to the "ulitimate" display clipping rectangle. Not a lot of help. The region encoding is (quite clearly) not documented. Apple can change it. I imagine that a hardward assisted quickdraw would be a likly reason to change it. ben hyde, cambridge