Rick, What OS are you using TUIO/OSC on? If you do iPad stuff, you do not need that as the iOS VM and image can support touch. Phil On Thu, Feb 20, 2014 at 6:51 PM, kilon alios <kilon.alios@gmail.com> wrote:
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 <self@je77.com> 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, phil@highoctane.be <phil@highoctane.be>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 <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
-- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick