The meaning of "the mouse" in 2.0

[Dar Scott]

On Wednesday, July 2, 2003, at 02:15 PM, Jim Hurley wrote:

> I am curious about this change in the meaning of "the mouse" in Run 
> Rev 2.0

 From 'What's New.txt' that came with my download:

      - The "mouse" function now reports the state
      of the mouse button at the moment the function
      is called. Formerly, this function reported
      whether the mouse button had been pressed since
      the current handler started. (In general, it is
      recommended to handle the "mouseDown", "mouseRelease",
      and "mouseUp" messages rather than check the state of
      the "mouse" in a handler.)

>
> In the past the following staple from HC:
>
> on mouseDown
>   repeat while the mouse is down
>     set the loc of me to the mouseLoc
>   end repeat
> end mouseDown
>
> was not only frowned upon because it exhausted the CPU,  but, at least 
> on the Mac, there was an intermittent bug in the engine which caused 
> the mouse to stick to the button even after a MouseUp.
> Is the bug gone?

Whether it be bug or not, the behavior is not the same.


> Is there some way in  which we can experiment with Mouse down, 
> mouseClick etc. to see  how a handler consumes CPU time using the 
> ability of the debugger in RR 2.0 to display messages? For example I 
> was curious to see how mouseclick compared with mouse is down.

CPU Monitor

On my OS X I can use CPU Monitor.  I have two processors so it shows 
two meters.

With the above function, usage jumps so that the total of the two 
meters is 100% of one processor.  Either one is max'd and the other is 
minimal or both are about half way.

However, this loop is not the same:

on mouseDown
   repeat while the mouse is down
     set the loc of me to the mouseLoc
     wait 20 milliseconds
   end repeat
end mouseDown

This usually barely shows on either meter but will sometimes peak at 
50% of one processor.  Changing the delay to .1 seconds makes the 
handler not show up at all on the meters.  The drag is a little jerky 
at .1 s, but is quite acceptable on my computer.

I think there is a lesson here.  Maybe it is the #3 missing from my 
list.

3.
Use wait in tight polling loops.  If you just have to use a loop.  This 
might apply to other loops such as a read from a serial port.  If you 
just have to use a loop.  Leave out the wait and you consume too much 
CPU.

If you don't have this utility you can build a standalone that, uh, 
does something clever.

Dar Scott