|Anonymous | Login||09-28-2020 23:08 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details [ Jump to Notes ]||[ View Advanced ] [ Issue History ] [ Print ]|
|ID||Category||Severity||Reproducibility||Date Submitted||Last Update|
|0003736||[Squeak] Graphics||minor||always||05-30-06 09:25||07-10-06 02:22|
|Summary||0003736: In 7032 (and 6665) Borders are drawn incorrectly when width is larger than Morph|
For this one
Get a Rectangle from supplies.
give it a wide red border.
shrink it to minimum width with large height or vice versa.
The border will cause a trapazoid to be drawn to the left or top (in the vice versa case)
This trapezoid will go in and out of existance as various things clip and redraw.
Now give the rectangle a gradient fill and another glitch related to the fill will appear also.
see also mantis 0000564 for another example of these glitches with SelectorMorph.
So there is probably more than one source of bug here.
One root issue is in Rectangle methods.
A Proper rectange has an origin strictly aboveLeft or equal to the corner.
Rectangle methods like insetBy: and expeandBy: or even fromUser assume it is alright to return improper rectangles. They were being optimized for speed I imagine.
Other rectangle methods like intersect: assume that their inputs are proper. Again an optimization for speed probably the reason.
The result is something of a horror to deal with.
Fixing just insetBy: to return a proper rectangle creates a different glitch.
The fact that gradient fill causes a glitch also leads me to suspect that the ballon engines assumption about getting proper rectangles need to be put to the test also.
A 3 pipe puzzle to be sure.
Any hints Andreas?
I've uploaded LargeBorderSmallRectange.gif
Which is a collection of snapshots of the same rectangle morph as it is rotated 0 to 90 by 15 I think the border was 35 unit wide and the morph 1 unit thin.
|Attached Files||LargeBorderSmallRectange.gif [^] (8,262 bytes) 05-30-06 09:25|
(0005660 - 40 - 40 - 40 - 40 - 40 - 40)
|Any fixes available before 3.9 goes out?|
(0005701 - 296 - 338 - 338 - 338 - 338 - 338)
I don't have one prepared.
The immediate type fix is to limit borderwidth to not exceed the morph bounds.
I haven't attempted to find that patch because it seems to me each morph has its own policy for borders.
I better leave the immediate answer as no since 3.9 seems so close.
|05-30-06 09:25||wiz||New Issue|
|05-30-06 09:25||wiz||Status||new => assigned|
|05-30-06 09:25||wiz||Assigned To||=> andreas|
|05-30-06 09:25||wiz||File Added: LargeBorderSmallRectange.gif|
|07-09-06 06:55||andreas||Note Added: 0005660|
|07-09-06 06:55||andreas||Status||assigned => feedback|
|07-10-06 02:22||wiz||Note Added: 0005701|
| Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
42 total queries executed.|
32 unique queries executed.