[plt-scheme] Possible OS X universe bug: Mouse starves for the sake of pretty scenery?

Hi all,

[I considered filing the following as a bug report, but the bug seems  
to require bitmaps in the relevant program source...]

Two of my students implemented a "whack-a-mole" game that worked  
nicely on the school machines (Vista PCs, about 1+1/2 years old), but  
locks up the world window on my home machine (2GHz Intel Core 2 Duo,  
OS X 10.5.8, 2GB RAM but w/DrScheme's memory limit set to 512MB).

I've stripped down their code (so be assured, they do follow the  
recipes) to the attached file that demonstrates the problem; I've  
tested it on the latest pre-release build of 4.2.3.2, and on an older  
stable version (4.1.5).

The code uses a timer field in the world to track when a mole should  
disappear.  In the original code, the world appears to freeze when a  
mole appears, and it becomes responsive again when it disappears.  By  
"freeze", I mean that mouse events appear not to be processed:  the  
"hammer" image doesn't move, and running big-bang with (state true)  
shows that the mouse cursor position is not changing.  (DrScheme also  
won't allow closing the world window.)  So I'm guessing the mouse  
event handler is being starved out by timer updates done by the tick  
handler, or redraw events for the (non-visibly-)changing world.

This problem seems to be solved by:
  * Setting the tick duration to a larger value, e.g. (on-tick update- 
world 1/4).
  * Using smaller background dimensions.
  * Using (rectangle ...) instead of the bitmap tiling for the  
background image.

Of course, I don't want to tell the students NOT to use a decent- 
looking background or keep it smaller than 600x600.  Is there an  
alternative for situations where slowing down the ticks is not an  
option?

Thanks,
jmj

-------------- next part --------------
A non-text attachment was scrubbed...
Name: w-a-m.ss
Type: application/octet-stream
Size: 46805 bytes
Desc: not available
URL: <http://lists.racket-lang.org/users/archive/attachments/20091124/235927e0/attachment.obj>
-------------- next part --------------