Thanks for that. Based on that, I investigated a bit further. It seems to be a touch UI problem. I'm using TUIO to read touch events. When doing animations, the OSC process (at user background priority) fails to trigger. I need to change how I use the OSCServer.
Cheers, Jeff On Thu, Feb 20, 2014 at 5:48 PM, [email protected] <[email protected]>wrote: > 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 <[email protected]> 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 >> > > -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
