Mantis Bugtracker
  

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0002453 [Squeak] Graphics major always 01-08-06 00:42 02-06-11 23:48
Reporter wiz View Status public  
Assigned To FrankShearar
Priority normal Resolution fixed  
Status closed   Product Version 3.9
Summary 0002453: [Bugs] What is the extent of a truncated rectangle?
Description "What is the extent of a truncated rectangle?" is a trick question.

I came across this beauty while tracking down the cause an fix for rotated moprhs losing their border pixels (Mantis 0002259 and before that 0000360).

The answer isn't what you would expect and depends on where the rectangle is placed in relation to the origin.

In particular the assumption that :

aRectangle truncated extent = aRectangle extent truncated

is not always correct.

to see this evaluate:
(1.5 asPoint extent: 3 asPoint) truncated extent " answers 3@3"
vs
(1.5 negated asPoint extent: 3 asPoint) truncated extent "answers 2@2"

and of course:
(1.9 negated asPoint extent:3.8 asPoint) truncated extent "answers 2@2"








Additional Information The bug is not in the behaviour of truncated its spec is to truncate to zero.
The bugs arise in the use of truncated in relation to rectange.

Many methods use truncation in conjunction with rectanges under the assumption that they will be used under the circumstances where this will lead to the correct result. Often they are mistaken.

I've made this a separate issue because I believe it will prove to be a factor in a lot more bugs than the one that lead me to discover it.

I am also not sure what is the correct solution. What you want to do with rectange depends on whats most important.

Getting all of it into the clipping box.
Preserving the location of its center.
Perserving extent truncated.
Preserving extent rounded.

etc.

The torture case is rotating a odd by even or even by odd rectangle with the zero point at its center with the rectangle being inset by a small fractional extent first.

Why would anyone do that? I don't know. But I also don't know that they wouldn't.

Rectangles need more options than just truncating and rounding. And this bug needs to be broadcast and documented. Plus there ought to be a few tests written to make clipping boxes containg their morphs bounds.
Attached Files  GlitchesFm3.9a6665.gif [^] (9,938 bytes) 01-19-06 03:03
 TruncatedPurple.gif [^] (10,224 bytes) 01-19-06 03:04
 RoundedPurple.gif [^] (10,541 bytes) 01-19-06 03:05
 RectangleTest-testRoundingAfterHalfPixelTranslation.st [^] (668 bytes) 04-29-10 06:01

- Relationships
child of 0006511new  Mother of all Morphic Graphical off-by-one/fencepost -error reports. 

- Notes
(0003548 - 1943 - 2117 - 2117 - 2229 - 2229 - 2229)
wiz
01-19-06 03:00

Ah, found a marvelous way to demonstrate this in action.

Get a rulerMorph from objects. Adjust to 50x25. Rotate a little to get a renderer then scale up to maximum magnification. Unrotate so we are just looking at the magnified ruler.

In preferences ask halos for a box around bounds.
You can put a halo around the magnified ruler and note the extra space between the magnified border of the ruler and the bounds of the rendering Tmorph (that has the halo).

Now here's where the marvelous part comes in.

From objects grab an ellipse. Place it over the magnified ruler and embed it into the ruler. You get an instant magnified ellipse.

Now you can get the halo to go over the ellipse. You have to click on a portion of the ellipse that intersects the bounds of the magnified ruler.

Once you have done that you can see the bounding box around the ellipse.

You can use the brown handle to move the ellipse around. Note how the size of things change as you move from the peripheriry thru the midpoint of the magnified ruler which is the zero point in the local space of the ellipse.

The clincher are the artifacts left behind by the ellipse as it move.

As you move left to right the trailling edge will leave unchanged border pixels behind. The height of these artifacts grow dramatically as the midpoint of the ruler is passed.

Finally I got very courageous and ask the ellipse for a gradient fill. (See Mantis 0000858 for more gruesome details of that problem). Moving that poor ellipse around was a very good way to see worst case results.

I've uploaded a resulting picture. (Look at the gribbles on the top. The gribbles on the bottom came from the right to left part of the cycle.)

Howerer, now you have an exciting way to see for yourself.

Yours in service, -- Jerome Peace

P.S. I've also made some demo pictures of the difficulty with truncation and rounding for rectangles Posted here also.
 
(0013738 - 990 - 1152 - 1152 - 1152 - 1152 - 1152)
wiz
04-29-10 06:06
edited on: 04-29-10 06:09

Uploaded an sunit test.
RectangleTest-testRoundingAfterHalfPixelTranslation.st

Right now the test fails.

This essentially demonstrates that Rectangles when their dimensions are rounded will change shqpe when their origin and corner are not in the same quadrant.

The translation by 0.5 happens quite frequently in practice. One need only render a morph whose bounds extent is odd in one of its dimensions.
This roundoff problem accounts for some of the gribbles morphs will leave on the screen.

For the problem to occur bump must equal 0.5
at 0.4 or o.6 the extents will match.

Below is the workspace version of the test.




trouble := 10 negated asPoint rect: 10 asPoint .
bump := 0.5 .
noTrouble := trouble translateBy: 15 .

10 timesRepeat: [ trouble := (trouble translateBy: bump ) rounded . ] .
10 timesRepeat: [ noTrouble := (noTrouble translateBy: bump ) rounded . ] .

trouble extent = noTrouble extent ifFalse: [ nil error: 'see what I mean'].

 
(0013991 - 118 - 130 - 442 - 442 - 442 - 442)
nicolas cellier
12-17-10 22:10

fixed in
http://source.squeak.org/trunk/Graphics-fbs.162.mcz [^]
http://source.squeak.org/trunk/GraphicsTests-fbs.27.mcz [^]
 
(0013995 - 79 - 79 - 79 - 79 - 79 - 79)
KenCausey
12-18-10 17:11

Assigned to Frank for the credit. He is fbs I think (and hope). Laziness ftw.
 
(0013996 - 29 - 29 - 29 - 29 - 29 - 29)
FrankShearar
12-18-10 17:19

Thanks, Ken! (Yes, fbs is I!)
 

- Issue History
Date Modified Username Field Change
01-08-06 00:42 wiz New Issue
01-08-06 00:42 wiz Status new => assigned
01-08-06 00:42 wiz Assigned To  => KenCausey
01-09-06 20:33 KenCausey Assigned To KenCausey => andreas
01-09-06 20:33 KenCausey Category Any => Graphics
01-19-06 03:00 wiz Note Added: 0003548
01-19-06 03:03 wiz File Added: GlitchesFm3.9a6665.gif
01-19-06 03:04 wiz File Added: TruncatedPurple.gif
01-19-06 03:05 wiz File Added: RoundedPurple.gif
05-25-07 02:52 wiz Relationship added related to 0006511
05-25-07 02:58 wiz Relationship replaced child of 0006511
04-29-10 06:01 wiz File Added: RectangleTest-testRoundingAfterHalfPixelTranslation.st
04-29-10 06:06 wiz Note Added: 0013738
04-29-10 06:09 wiz Note Edited: 0013738
12-17-10 22:10 nicolas cellier Status assigned => resolved
12-17-10 22:10 nicolas cellier Fixed in Version  => trunk
12-17-10 22:10 nicolas cellier Resolution open => fixed
12-17-10 22:10 nicolas cellier Note Added: 0013991
12-18-10 17:11 KenCausey Note Added: 0013995
12-18-10 17:11 KenCausey Assigned To andreas => FrankShearar
12-18-10 17:19 FrankShearar Note Added: 0013996
02-06-11 23:48 leves Status resolved => closed


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