QuickDraw arc oddities revisited

[angus@arti9.vub.ac.be (Angus McIntyre)]

Thanks to all who wrote, as they say ... 

Robert Bruce Findler <robby+@cmu.edu> writes:

> It's hard to tell what's wrong from your description. Can you send the
> code that is messing up? One thing that comes to mind immediately is do
> you have color-p true in the initargs of the window?
Code will follow. As you'll see from the code, I do set 'color-p' to true
(but the same thing happens with it set to NIL).

"John W. Baxter" <jwbaxter@pt.olympus.net> writes:

> My guess is that your arc-drawing problems stem from not properly setting
> up the state of the graphport before making each arc-drawing call.  As if
> you and MCL are "fighting" over the various state variables, and MCL is
> winning.  When you trigger your screen saver on and off (that IS a handy
> trick, isn't it!!), you are giving your code a chance to run without so
> much "help" from MCL (all in one update).
That makes sense, although it seems strange to me that I haven't run across
this problem with other QuickDraw calls. I've tried both using the QuickDraw
interfaces and calling the traps directly, and it doesn't make a difference.
On the other hand, different context switches seem to have different effects;
as mentioned, the screen saver forces it to get its act together and so,
apparently, does switching to and from the Finder (at least for any part
of the graph that is covered up by Finder windows). Covering part of the
diagram with windows from other applications doesn't seem to have a reliable
effect (e.g. I get the bad behaviour rather than the good). On the other hand,
under certain non-reproducible circumstances particular MCL windows may cause
a correct redraw.

> I could be way off base.  But...the QuickDraw arc routines are 10 years old
> (the version you're running is more like 4 or 5 years old, true)...problems
> such as you describe--if in QuickDraw--would have been fixed by now.
I know - this is what's bothering me. This is The Impossible Bug, but it
seems to be happening all the same, and without the help of outsiders to
point out the boneheaded error that I *must* be making somewhere, I can't
immediately see what I'm doing wrong. Hence my appeal for help.

OK, here's the code - it's not actually the code that initially generated
the problem, but it's a simplification of it which produces the same
result. The behavior that *I* get is that instead of a multi-colored pie,
I get a large colored circle. If I force a redraw with extreme prejudice
(e.g. by switching in the screensaver), then I get a multicolored pie, the
way I wanted it.

In this example, the random element makes for some rather strange effects
when only part of the pie needs to be updated, but it should be clear when
it's getting it right - narrow pie segments of color - and when it's getting
it wrong - large swatches of all one color.

Can someone run this and let me know if they get the same problems on their
system? Or can anyone spot something simple and obvious that I'm doing wrong?

Many thanks,

                Angus

-----------------------------------------------------------------------------

(defclass PROBLEM-WINDOW (window)
  ()
  (:default-initargs
    :view-size #@(400 400)
    :color-p T))

(defmethod VIEW-DRAW-CONTENTS ((Window problem-window))
  (rlet ((Rectangle :rect))
    (rset Rectangle :rect.topleft #@(0 0))
    (rset Rectangle :rect.bottomright (view-size Window))
    (do* ((StartAngle 0)
          (ArcAngle   (1+ (random (- 360 StartAngle)))
                      (1+ (random (- 360 StartAngle))))
          (Color      (make-color (random 65536)
                                  (random 65536)
                                  (random 65536))
                      (make-color (random 65536)
                                  (random 65536)
                                  (random 65536))))
         (NIL)
      
      (with-fore-color Color
        (fill-arc Window *black-pattern* StartAngle ArcAngle Rectangle))
      (when (>= (incf StartAngle ArcAngle) 360) (return)))))