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 <[email protected]> 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 <[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 >> > >
