I would be surprised to see more than a WorldState instance for each World. A World, the entire Smalltalk screen, is a PasteUpMorph. Morphic-Worlds is the package that manages all this. PateUpMorph>>runStepMethods worldState runStepMethodsIn: self 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. Double dispatching crazyness aside, I doubt the pause affects anything like you say. Philippe 2012/9/8 Igor Stasenko <siguctua@gmail.com>
On 5 September 2012 08:25, phil@highoctane.be <phil@highoctane.be> wrote:
Stepping methods are called in the main UI thread but they aren't drawing anything.
Then, what is the default cycle?
Have a look at MorphicUIManager for answers, especially spawnNewProcess, which basically does this:
spawnNewProcess
UIProcess := [ [World doOneCycle. Processor yield. false] whileFalse: []. ] newProcess priority: Processor userSchedulingPriority. UIProcess resume
World doOneCycle and the userSchedulingPriority are at play here.
This will lead us to
WorldState >> doOneCycleFor: aWorld "Do one cycle of the interaction loop. This method is called repeatedly when the world is running. This is a moderately private method; a better alternative is usually either to wait for events or to check the state of things from #step methods."
self interCyclePause: MinCycleLapse. self doOneCycleNowFor: aWorld.
And, yeah, here it is:
WorldState >> interCyclePause: milliSecs "delay enough that the previous cycle plus the amount of delay will equal milliSecs. If the cycle is already expensive, then no delay occurs. However, if the system is idly waiting for interaction from the user, the method will delay for a proportionally long time and cause the overall CPU usage of Squeak to be low. If self serverMode returns true then, always do a complete delay of 50ms, independant of my argument. This prevents the freezing problem described in Mantis #6581"
| currentTime wait | self serverMode ifFalse: [ (lastCycleTime notNil and: [CanSurrenderToOS ~~ false]) ifTrue: [ currentTime := Time millisecondClockValue. wait := lastCycleTime + milliSecs - currentTime. (wait > 0 and: [ wait <= milliSecs ] ) ifTrue: [ (Delay forMilliseconds: wait) wait ] ] ] ifTrue: [ (Delay forMilliseconds: 50) wait ].
lastCycleTime := Time millisecondClockValue. CanSurrenderToOS := true.
Well, you may want to tweak this a bit to get a feel on how things do work under Athens there.
This is all generic Morphic in 1.4 so, you may be in for some differences with Athens. Isn't that big 50 millisecs hardcoded magic number nice :-( ? Maybe can there be a pref for that?
it is a default intercycle pause. actually you can set #stepTime to be 0 .. then this pause won't affect anything. If i not mistaken. If i do, then yes, it would be good to be able to dynamically change the pause depending on needs of world's morphs (i.e. #stepTime)
Enjoy,
Philippe Back
-- Best regards, Igor Stasenko.