I've done such a kind of app (without Athens but with Morphic) on the iPad.

I works nicely.

Now, MorphicUIManager>>spawnNewProcess tells us:

spawnNewProcess

UIProcess := [
[World doOneCycle. �Processor yield. �false] whileFalse: [].
] newProcess priority: Processor userSchedulingPriority.
UIProcess name: 'Morphic UI process'.
UIProcess resume


So, World doOneCycle forever.

World being a PasteUpMorph

then we enter this ping pong of double dispatches in the the doOneCycle (I think this could be utterly simplified but hey, it takes courage to go in there. I've got my own scribbled map but it would take quite a while to change things. Add to that that Stef and Igor appear to be working on some event internals so that all of the previous knowledge will be moot...)


PasteUpMorph>>doOneCycle
� worldState doOneCycleFor: self

with worldState being a WorldState

at one point, the worldState will call the World>>drawOn: aCanvas

Which happens under:

WorldState>>doOneCycleNowFor: aWorld
"Immediately do one cycle of the interaction loop.
This should not be called directly, but only via doOneCycleFor:"

DisplayScreen checkForNewScreenSize.

"process user input events"
LastCycleTime := Time millisecondClockValue.
self handsDo: [:h |
ActiveHand := h.
h processEvents.
ActiveHand := nil
].

"the default is the primary hand"
ActiveHand := self hands first.

aWorld runStepMethods. "there are currently some variations here"
self displayWorldSafely: aWorld.

runStepMethods call into the runLocalStepMethodsIn: aWorld

where all kinds of old things show up (like priorWorld where we do not have that anymore, as we only have one now�.

and where the stepList is also processed and this:

(now < lastStepTime or: [now - lastStepTime > 5000])�
ifTrue: [self adjustWakeupTimes: now]. "clock slipped"

takes place (I wonder why, someone can explain?)

And if the stepList isn't empty, it will go through all step methods:

[stepList isEmpty not and: [stepList first scheduledTime < now]]�
whileTrue:�
[lastStepMessage := stepList removeFirst.
morphToStep := lastStepMessage receiver.
(morphToStep shouldGetStepsFrom: aWorld)�
ifTrue:�
[lastStepMessage value: now.
lastStepMessage ifNotNil:�
[stepTime := lastStepMessage stepTime ifNil: [morphToStep stepTime].
lastStepMessage scheduledTime: now + (stepTime max: 1).
stepList add: lastStepMessage]].
lastStepMessage := nil].
lastStepTime := now.


Ah, now + (stepTime max: 1)... guess that zero will not cut it then. Minimum stepTime will at least be one.

This explains that I guess.

The Squeak 4.3 doOneCycleNowFor: aWorld is more or less similar (it has a capturingGesture thing but without effect).

And the stepTime has also the max:1 thing.

runLocalStepMethodsIn: aWorld�
"Run morph 'step' methods (LOCAL TO THIS WORLD) whose time has come. Purge any morphs that are no longer in this world.
ar 3/13/1999: Remove buggy morphs from the step list so that they don't raise repeated errors."

| now morphToStep stepTime priorWorld |
now := Time millisecondClockValue.
priorWorld := ActiveWorld.
ActiveWorld := aWorld.
self triggerAlarmsBefore: now.
stepList isEmpty�
ifTrue:�
[ActiveWorld := priorWorld.
^self].
(now < lastStepTime or: [now - lastStepTime > 5000])�
ifTrue: [self adjustWakeupTimes: now]. "clock slipped"
[stepList isEmpty not and: [stepList first scheduledTime < now]]�
whileTrue:�
[lastStepMessage := stepList removeFirst.
morphToStep := lastStepMessage receiver.
(morphToStep shouldGetStepsFrom: aWorld)�
ifTrue:�
[lastStepMessage value: now.
lastStepMessage ifNotNil:�
[stepTime := lastStepMessage stepTime ifNil: [morphToStep stepTime].
lastStepMessage scheduledTime: now + (stepTime max: 1).
stepList add: lastStepMessage]].
lastStepMessage := nil].
lastStepTime := now.
ActiveWorld := priorWorld


So, I wonder why it would be different in Squeak.

HTH

Phil















�



On Thu, Feb 20, 2014 at 5:16 PM, J.F. Rick <self@je77.com> wrote:
Athens graphics are fast enough that it is possible to do high frame-rate animations. I've been trying (and, to various degrees, succeeding) in adding animations to my touch applications. I'm using stepping to do it. Basically, you just move pieces / update the display when step gets called. If you set the stepTime to 30, you should get somewhere around 30 frames per second, which is quite smooth.

The problem I have is that the step mechanism in Pharo seems to block out the UI thread. In Squeak, you could return 0 for the stepTime message and then step would get called each UI cycle. In Pharo, the two seem to be disconnected. If the stepTime is too low, the processor will be busy doing redrawing and the UI loop is stopped. When I do stepTime of 20, the UI stops responding until after the animation is over. When I do stepTime of 50, the UI keeps working. The lower the stepTime, the smoother the animation, but also the chance that the UI becomes unresponsive. That's a nasty tradeoff. Is there a good way to do step style animation without this tradeoff? Why was stepping and the UI loop separated? Is there a different way that animation should be implemented?

Cheers,

Jeff

--
Jochen "Jeff" Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick