0001914: [Bug] On a form canvas drawing rectangles after filling ovals makes the rectangles the wrong color.

Notes
(0002813 - 396 - 408 - 408 - 408 - 408 - 408) andreas 10-10-05 10:24 edited on: 10-10-05 10:25	I'm not quite certain I consider this a bug - the particular mix of drawing operations is quite unusual. Generally one should go for either for canvas operations (fillOval: and frameAndFillRectangle) or balloon operations (drawOval: and drawRectangle:). Mixing them like in this code can certainly lead to odd effects and it's not certain that it's worthwhile putting the effort in to fix them.

(0002829 - 1654 - 1765 - 1765 - 1765 - 1765 - 1765) wiz 10-12-05 03:38	Alright, It was late at night and I was hasty. My analysis rushed. BalloonCanvas is not as innocent as I thought. Drawrect uses the balloon engine to draw the rectange. FillOval checks to see if the rectange is affected by the transform and then chooses to either drawOval (using balloon engine) or to call super (FormCanvas) which is where the problem starts. bc ifNoTransformWithIn: box is the check an when it is set (as suggested by a comment within it) to always return false the problem goes away because drawOval is called which, as Andreas points out, is consistant with what balloon engine is set to work with. Now as to whether and what type of bug this is I differ. If you know all that andreas knows it is not a bug but a misuse of the language. But if you are learning by using squeak? Where is the manual that says mixing these is verboten? The routine fillOval itself calls both. And that invites confusion. The balloon stuff Andreas wrote is some of the best stuff in town. It provides a way to get performance out of Squeak. Its under used now because it doesn't mesh seamlessly with the other drawing stuff in squeak. Also it is not always complete or completely debugged. It was made to work up to a point and then left on its own. My general experience with it is that it is too much fun to leave in this state. So it deserves attention and "fixing" so that it can work well with its neighbors. And Hans code certainly deserves as a reproducible anomily to be in a bug report. So Andreas is there a place to go to get a guide to the differences one needs to be aware of when using BalloonCanvas?

(0002832 - 220 - 244 - 244 - 244 - 244 - 244) andreas 10-12-05 07:08	> So Andreas is there a place to go to get a guide to the differences one needs > to be aware of when using BalloonCanvas? Of course not (as if you expected differently ;-) So how do you propose to fix the problem?

(0002856 - 1263 - 1383 - 1383 - 1383 - 1383 - 1383) wiz 10-14-05 03:21	>Of course not (as if you expected differently ;-) So how do you propose to fix the problem? With time, patience and elegance! First I have to figure out what's in that manual that doesn't exist. The clue you gave about fillThings being in a different universe than drawThings is helpful. If bc>fillOval always took the drawOval branch rather than using super that would do the trick for this particular example. Was there a reason you called super in the "simple" case? Does it save time or space? Secondly, this is just a feeder problem for the more important one of how to get the balloon drawing stuff to be more useful in squeak in general. So in that sense the fix is to find someone to create the non existant manual (or pamplet ). Thirdly, the problem is here on Mantis. Neither you nor I are required to come up with a solution. Just being helpful along the way is partial progress. Others read these reports too. And someone out there might have another clue or hankering to help either with the code or the documentation. Just remember what Tonto said when the Lone Ranger and he were surrounded by Indians and the Lone Ranger remarked. "Looks like we're in trouble Tonto." Tonto reply was: "What do you mean we, Kimosabe?"

(0002997 - 2669 - 4471 - 4471 - 4471 - 4471 - 4471) baveco 10-27-05 09:27	I encountered another, likely related, problem, with #drawString this time :-) I know I can use morphs all the way up and down to produce graphs, but it is funny to experiment a bit and also nice to have all display logic in one single #drawOn: method. So I posted the following to squeak dev: In my clumsy attempts at displaying circles, squares, polygons and text on a (Balloon) Canvas, I keep running into strange behavior that to me looks like canvas properties that are sometime updated and sometimes not, and sometimes not even set at all... Maybe this is systematic, but currently I am lost how to achieve my relatively simple goal. (in a previous post I mixed #drawRectangle:color:borderWidth:borderColor: with #fillOval:color:borderWidth:borderColor: and the resulting colors were not what I suspected. For some reason (why?) mixing these type of methods is an unusual thing to do...) Current problems: 1) Using drawOval:etc instead of fillOval:etc results in circles with correct colors. However, mixing circles and squares with text (using drawString:at:font:color:) results again in strange interference effects. See the code below. Displaying the string on another canvas is ok; displaying the string on the same canvas distorts the following display of rectangles and circles. Is drawString:at:font:color: a method of the #fillXXXX type, that should not be mixed with #drawXXXX methods?? If so, how to draw String then? 2) Is drawOval:etc the best way to draw circles with borders? Under some circumstances the borderColor doesnot appear (havent figured out exactly when). And anyway the results are not that visually pleasing - so I wondered whether there exist an alternative drawing method? As I am not sure these things are bugs and not features so I'll wait with posting them on Mantis. Hans \| bc offset posRect count font bc2 \| bc := BalloonCanvas on: Display. bc2 := BalloonCanvas on: Display. offset := 50 @ 50. posRect := -5 @ -5 extent: 11 @ 11. font := TextStyle defaultFont. count := 0. (Array with: bc2 with: bc) do: [:theBC \| "when theBC == bc strange things happen..." 1 to: 2 do: [:i \| theBC drawString: 'just a String' at: (offset + (count * (50@0))) font: font color: Color red. { (Color red). (Color blue). (Color yellow). (Color green) } do: [:each \| count := count + 1. bc drawRectangle: (posRect translateBy: (offset x * count) @ 10) color: each borderWidth: 1 borderColor: Color black. bc drawOval: (posRect translateBy: (offset x * count) @ 30) color: each borderWidth: 1 borderColor: "each "Color black]] ]

(0002998 - 155 - 155 - 155 - 155 - 155 - 155) andreas 10-27-05 09:37	I think I should acknowledge the issue at least. Yes, those are bugs. It's just ... that I have no friggin' idea how to fix them. Patches are very welcome!

Issue History
Date Modified	Username	Field	Change
10-10-05 08:56	wiz	New Issue
10-10-05 10:24	andreas	Note Added: 0002813
10-10-05 10:25	andreas	Note Edited: 0002813
10-12-05 03:38	wiz	Note Added: 0002829
10-12-05 07:08	andreas	Note Added: 0002832
10-14-05 03:21	wiz	Note Added: 0002856
10-27-05 09:27	baveco	Note Added: 0002997
10-27-05 09:37	andreas	Note Added: 0002998
10-27-05 09:37	andreas	Status	new => acknowledged

Relationships