Mantis Bugtracker

Viewing Issue Advanced Details Jump to Notes ] View Simple ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0001914 [Squeak] Graphics minor always 10-10-05 08:56 10-27-05 09:37
Reporter wiz View Status public  
Assigned To
Priority normal Resolution open Platform
Status acknowledged   OS
Projection none   OS Version
ETA none Fixed in Version Product Version 3.9
  Product Build
Summary 0001914: [Bug] On a form canvas drawing rectangles after filling ovals makes the rectangles the wrong color.
Description Hot off the press (Well squeak-dev anyway)

[Balloon] BalloonCanvas bug?
Baveco, Hans Hans.Baveco at
Sun Oct 9 22:37:39 CEST 2005

When displaying square and round dots in different colors with the
following test code, the BalloonCanvas appears to mesh up the colors.
Red-red-blue-red rectangles appear, instead of the expected
When I change the order within the block, with first the #fillOval:etc
and then the #fillRectangle:etc, the results are as expected though.
Something weird is going on here, with #fillOval:etc always updating the
color and #fillRectangle:etc not.


    | bc offset posRect count |
    bc := BalloonCanvas on: Display.
    bc aaLevel: 2.
    offset := 50 @ 50.
    posRect := -5 @ -5 extent: 11 @ 11.
    count := 0.
    { (Color red). (Color blue). (Color red). (Color blue) } do:
                [:each |
                count := count + 1.
                    drawRectangle: (posRect
translateBy: (offset x * count) @ 10)
                    color: each
                    borderWidth: 0
                    borderColor: each.
                    fillOval: (posRect translateBy:
(offset x * count) @ 30)
                    color: each
                    borderWidth: 0
                    borderColor: each]

or a simpler case

| bc posRect |
    bc := BalloonCanvas on: Display.
    bc aaLevel: 2.

    posRect := -5 @ -5 extent: 11 @ 11.

                    drawRectangle: (posRect translateBy: (50) @ 30)
                    color: Color blue
                    borderWidth: 0
                    borderColor: Color cyan. bc
                    fillOval: (posRect translateBy:(50) @ 50)
                    color: Color red
                    borderWidth: 0
                    borderColor: each .

                    drawRectangle: (posRect
translateBy: (50) @ 70)
                    color: Color blue
                    borderWidth: 0
                    borderColor: Color cyan.] value

The second rectangle will be red not blue .

For some odd reason the bug will only occur after one rectangle is drawn correctly. This must be setting up some state which the next rectange believes to be undisturbed and the intervening oval of course has changed.

Steps To Reproduce
Additional Information fillOval: etc. causes the GrafPort fillPattern to be set when it sends its receiver a setFillColor: message.

drawRectangle leaves fillPattern alone at least on the second pass.
So if it is set then the drawRectangle color parameter is trumped by the fillPattern parameter it didn't set.

The balloon engine is relatively innocent. This was a great bug find and a fine reproducable pattern. Thanks Hans.

A fix is still needed.
Are there any undesirable side affect to adding a setFillColor: to drawRectangle?
Will fixing up the one drawRectange routine do it.

Before setFillColor: is sent. If it is never sent drawRectange works with colors as expected. What state is fillPattern in then and would a better fix be to have fillOval return it to that state?

Attached Files

- Relationships

- Notes
(0002813 - 396 - 408 - 408 - 408 - 408 - 408)
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)
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)
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)
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)
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:
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?

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.


| 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.
                    drawRectangle: (posRect translateBy: (offset x * count) @ 10)
                    color: each
                    borderWidth: 1
                    borderColor: Color black.
                    drawOval: (posRect translateBy: (offset x * count) @ 30)
                    color: each
                    borderWidth: 1
                    borderColor: "each "Color black]] ]
(0002998 - 155 - 155 - 155 - 155 - 155 - 155)
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

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