Mantis Bugtracker
  

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0000843 [Squeak] Morphic major always 01-22-05 08:25 12-26-06 02:22
Reporter wiz View Status public  
Assigned To
Priority normal Resolution open  
Status new   Product Version 3.9
Summary 0000843: Closed Curves (and Polygons) can cause Space Low problems.
Description Defining a closed polygon with verts ( 0@0 20000@20000 20001@19999) will probably cause the error. Or pick something equally ridiculous for your memory size.
  
Though this will probably not be done deliberately a curve morph can cause this problem for combinations of vertices that as a segmented curve will look ok. The low space bug happens because bounds are set before they are tested for reasonableness and filledForm allocates a Form trusting bounds to be reasonable.

FilledForm is nil for open curves and polys and I haven't check to see how they would fail under the same stressed conditions.


Additional Information A circuit breaker is needed to catch this bug and amend the polygon so that low space does not crash the image before the user can recover.
Attached Files  fillFormAreaCheck-wiz.13.cs [^] (3,828 bytes) 02-08-05 02:30
 ShadowVsFilled.gif [^] (8,176 bytes) 12-26-06 02:07

- Relationships

- Notes
(0001139 - 1229 - 1301 - 1301 - 1301 - 1301 - 1301)
wiz
02-08-05 02:29
edited on: 05-23-06 03:26

I mucked with filledForm and got it to check before trying to allocate to large a form. After putting in checks in places where filledForm was used this worked better than I expected. The polygon would draw and in the proper color. But a too large polygon would behave to the cursor as if it were transparent. ( Because containPoint relys on filledForm for closed non transparent polys).

This suggests that what is needed is to clip filledForm to the display boundries. Presumably that would handle all the cases we cared about.

As I was looking about I found out that a similar borderForm has the same problem. I did not realize this at first because borderForm is only activated for translucent (transparent?) borders.

So that probably needs a similar clipping to keep the size of the allocated form.

I don't have the experience or knowledge to figure out how to fix up the offsets from the original bounds to the clipping bounds. So if someone else can help that would be great. Else I'm putting this on a back burner and considering my part done in the reporting.

I've attached the most recent fillFormAreaCheck changeset. This is not an acceptable fix. However its useful in showing what I've tried.

 
(0001140 - 447 - 489 - 489 - 489 - 489 - 489)
wiz
02-08-05 02:37
edited on: 05-23-06 03:25

Another way to get a too large polygon.

Get the small size polygon from the parts bin. Move it to the top left of the screen.
Rotate it so the pointest part points allong the diagonal.
use the grow halo handle and pull down to the bottom right.
Now pick up the bottom right point of the poly and bring it back to the top left of the display. Repeat this several times and you will create a huge poly. Only the tip will be on the screen.

 
(0008758 - 1367 - 1485 - 1485 - 1485 - 1485 - 1485)
wiz
12-26-06 02:22

I put another round of thinking into this report/problem.

One reason is that the OLPC Etoys now has a way for the user the update an individual polygon point. Which means that there is one more way for polygons to "blow-up".

For some reason I am not sure of the filled formed is different from the shadow form. And it is not strickly faithful to all the interior voids in a not concave polygon. See the uploaded picture.

Extending that concept somewhat. What if contains point would mean the point falls within the convex envelope containing the polygon? This simpler definition would allow an array of envelop vertices to substitute for the filled form. And thus disaster could be avoided.

This would leave the border points to fend for themselves. But this too would be amenable to simply sequencing thru the linesegments to see if a point was within the correct distance of one of them.

If the speed of the above is a concern then predicate which of the two methods is used on the size of the forms that would have to be allocated.

If the area of a polys extent is more than a screenful then use the memory saving method. Else use the time saving one.

Hmmm.

The problem of finding the convex envelope for a complex polygon is proving its worth by figthing back. I am making good progress against it.

Yours in service, --Jerome Peace
 

- Issue History
Date Modified Username Field Change
01-22-05 08:25 wiz New Issue
02-08-05 02:29 wiz Note Added: 0001139
02-08-05 02:30 wiz File Added: fillFormAreaCheck-wiz.13.cs
02-08-05 02:37 wiz Note Added: 0001140
05-23-06 03:25 wiz Note Edited: 0001140
05-23-06 03:26 wiz Note Edited: 0001139
12-26-06 02:07 wiz File Added: ShadowVsFilled.gif
12-26-06 02:22 wiz Note Added: 0008758


Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
49 total queries executed.
30 unique queries executed.
Powered by Mantis Bugtracker