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

_______________________________________________
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Reply via email to