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

From: Matthias Felleisen (matthias at ccs.neu.edu)
Date: Wed Nov 25 10:15:16 EST 2009

We've looking into this. So far all I can say that your code had only  
one superfluous function call. It's us ...  -- Matthias

On Nov 25, 2009, at 2:48 AM, Jordan Johnson wrote:

> 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, 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
> <w-a-m.ss>
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme

Posted on the users mailing list.