Mantis Bugtracker
  

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0000564 [Squeak] Morphic minor always 11-25-04 21:34 10-09-07 03:11
Reporter wiz View Status public  
Assigned To
Priority normal Resolution open  
Status new   Product Version
Summary 0000564: glitch in rectangle draw routines can be seen with selector morph
Description In 3.9a mouse down to get a selector.
Stretch it out to the right, then move it to the top until it is very narrow.
Move it up slowly till it disappears then move it one or two pixels higher and move it immediately back down. An unerased line will be left on the screen.

This also works horizontally as well.
Additional Information This is not a selector bug but the selector is a great probe for exploring whats causing the glitches,

My guess it this is a clipping box problem an I suspect the clip box left is too far right. I have also seen behavior that make me wonder it the right side of the clipping box is too far right as well.

Why does the rectangle boarder dissappear completely at one point?
Why does the rectange not erase everything it has drawn?

What would happen if the borders were wider or narrower?
Attached Files  RectDrawGlitches.gif [^] (1,625 bytes) 11-25-04 21:34
 SelectorGlitches.gif [^] (1,700 bytes) 05-30-06 03:10

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

- Notes
(0005131 - 770 - 896 - 896 - 1106 - 1106 - 1106)
wiz
05-30-06 03:09

More analysis.

The glitches can be made more pronounced by increasing SelectorMorphs defaultBorderWidth.

in the uploaded pic SelectorGlitches.gif the width has been set to 15.

To get a horizontal glitch.
In a fresh 7032 (for example)

redefine SelectorMorph>>defaultBorderWidth to 15 (for dramatic effect.)
Hold shift down and press red mouse button ( a selector with a large border will appear)

Drag the mouse towards the bottomRight.
Drag the mouse to the left crossing the y axis of the origin.
Drag the mouse to the right again crossing the Y axis.
Release the mouse button.
(The right edge of the border remains behind as a screen glitch)

The same thing can be done horizontally.

The bug here may be related to Mantis 0002405 and 0002453
 
(0005171 - 2325 - 2685 - 2715 - 2715 - 2715 - 2715)
wiz
06-01-06 22:06

More observations

Borders for rectangles are inset from their bounds.

  A lot of the rectangle routines are optimized for speed (i.e. they don't check their inputs or outputs)

For example:
(0 asPoint corner: 10 asPoint ) insetBy: 35
"will create a rectangle with extent -25 asPoint."

The intersection of this with a rectangle at the same origin and extent 0 asPoint would also be a rectangle with an extent of -25.

Try
e0 := p0 := 0 asPoint .
r0 := p0 extent: e0 .
(p0 extent: -25 asPoint) intersect: r0

 "answers: 0@0 corner: -25@-25"
    
If we name these rectangles after the quadrant their extent appears in.
Proper rectangles are first quadrant rectangles.

 
Then the improper ones would can be called second , third and fourth quardrant. The example above is a third quadrant rectangle.

The difficult is arising from drawing routines that are implemented with confilicting assumptions.

- All my inputs will be forever proper. (intersect:)

- I will never get inputs that make me produce improper outputs. Of it I do those outputs will be checked before they are used. (insetBy:)

- Users my specifiy any extent for a morph. And any positive width for a border. (Morphic UI routines).

Even Rectangle fromUser would permit the user to choose improper corners w/o checking.

=====

Fixing the problem.

I don't know yet what will work.

Fixing the rectangle routines directly doesn't work or at least not simply.
Making insetBy: give a proper rectangle causes other things to break.

Also Balloon Engine seems to have great problems with borders. Probably a similar mismatch of assumptions about inputs. Worth its own report when I gather enough info to make it worth while.

The safest path to fixing would seem to be dynamically limiting morphic border widths so that the are guarenteed to lie within the bounds of the morph. One of the things that I noticed looks good is to have a border width that is set by the size of the morph. So instead of having a user input the width you could allow them only to input a fraction that determines the width in relation to the morphs size. That will make for good looking morphs. And when they are resized the border width will be readjusted to suit.

Well more next time,

Yours in service, --Jerome Peace
 

- Issue History
Date Modified Username Field Change
11-25-04 21:34 wiz New Issue
11-25-04 21:34 wiz File Added: RectDrawGlitches.gif
05-30-06 03:09 wiz Note Added: 0005131
05-30-06 03:10 wiz File Added: SelectorGlitches.gif
06-01-06 22:06 wiz Note Added: 0005171
10-09-07 03:11 matthewf Relationship added child of 0006511


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