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 <[email protected]> > On 5 September 2012 08:25, [email protected] <[email protected]> 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. > > >
