Interesting topic, there is also this http://www.smalltalkhub.com/#!/~vmariano/Pegasus
but I have not used it so I cant say how usable it is. On Thu, Feb 20, 2014 at 7:46 PM, J.F. Rick <[email protected]> wrote: > 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 >
