[?] Timers & Stepping (was: Morphic IV docs MorphicWorlds)
lex at cc.gatech.edu
Sat Mar 18 12:33:46 UTC 2000
"Jim Benson" <jb at speed.net> wrote:
> Here's an experiment that you can do to try to get better performance from
> the existing system. You can execute: 'PasteUpMorph MinCycleLapse: 0'.
Your other suggestions sound fine, but if decreasing this helps anything, then
there is a bug in the system. When the framerate gets below the threshold value,
this lapse should automatically go to zero anyway. That's why it's
called a *min* cycle lapse--it's is a minum time that goes between
the start of two cycles. If you specify 10 ms, and the cycle lapse
was already 40 ms, then the code should just return.
Here's a relevant code snippet:
wait _ self lastCycleTime + milliSecs - currentTime.
wait > 0 ifTrue: [
"do the wait..."
Anyway, I can verify that moving around several things at once will cause
drastic slowdowns in Morphic. On the other hand, it's not clear that it can do
better with it's basic model of directly manipulating a bitmap. Do the math some
time and see just how good you can expect things to get. Assume your computer can
copy 40 MB per second in RAM (is this a reasonable number? I have no
idea). Figure out how many bytes are shuffled by each of your images,
and then multiply by how many images you have. If the result is, say,
10 MB, you're never going to do better than 4 frames per second.
Another interesting test is to try "[myMorph displayOn: World canvas]
timeToRun" to see exactly how long each morph is taking to draw (not
counting transfering it to the video card, I don't think). Yet another
is "[Display forceToScreen: (0 at 0 extent: 100 at 100)] timeToRun" to test
out your VM and video setup.
Finally, as my one concrete suggestion, you can play
with decreasing the depth of the display and your OS's display depth.
This would mean you have fewer bits to shuffle around, which should
correspondingly speed things up. But no promises, you'll have to just try it :)
More information about the Squeak-dev