The Inbox: Morphic-ul.754.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

The Inbox: Morphic-ul.754.mcz

commits-2
Levente Uzonyi uploaded a new version of Morphic to project The Inbox:
http://source.squeak.org/inbox/Morphic-ul.754.mcz

==================== Summary ====================

Name: Morphic-ul.754
Author: ul
Time: 18 January 2015, 8:33:51.264 pm
UUID: 2e6f7fa2-e377-4374-99db-5be8fbad0013
Ancestors: Morphic-bf.753

Simplified and improved WorldState >> #interCyclePause:
- don't create a new Delay (along with a new Semaphore) every 20 (or 50) milliseconds
- use #millisecondsSince: to avoid the effects of the clock rollover
- separated the code of time calculation and actual waiting

Depends on Kernel-ul.893

=============== Diff against Morphic-bf.753 ===============

Item was changed:
  Object subclass: #WorldState
+ instanceVariableNames: 'hands activeHand viewBox canvas damageRecorder stepList lastStepTime lastStepMessage lastCycleTime commandHistory alarms lastAlarmTime remoteServer multiCanvas interCycleDelay'
- instanceVariableNames: 'hands activeHand viewBox canvas damageRecorder stepList lastStepTime lastStepMessage lastCycleTime commandHistory alarms lastAlarmTime remoteServer multiCanvas'
  classVariableNames: 'CanSurrenderToOS DeferredUIMessages DisableDeferredUpdates LastCycleTime MinCycleLapse'
  poolDictionaries: ''
  category: 'Morphic-Worlds'!
 
  !WorldState commentStamp: 'ls 7/10/2003 19:30' prior: 0!
  The state of a Morphic world.  (This needs some serious commenting!!!!)
 
 
  The MinCycleLapse variable holds the minimum amount of time that a morphic cycle is allowed to take.  If a cycle takes less than this, then interCyclePause: will wait until the full time has been used up.!

Item was changed:
  ----- Method: WorldState>>interCyclePause: (in category 'update cycle') -----
  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 the preference #serverMode is enabled, always do a complete delay of 50ms, independant of my argument. This prevents the freezing problem described in Mantis #6581"
 
+ | millisecondsToWait |
+ millisecondsToWait := Preferences serverMode
+ ifTrue: [ 50 ]
- | currentTime wait |
- Preferences serverMode
  ifFalse: [
+ (lastCycleTime notNil and: [CanSurrenderToOS ~~ false])
+ ifTrue: [ milliSecs - (Time millisecondsSince: lastCycleTime) ]
+ ifFalse: [ 0 ] ].
+ millisecondsToWait > 0 ifTrue: [
+ interCycleDelay
+ ifNil: [ interCycleDelay := Delay forMilliseconds: millisecondsToWait ]
+ ifNotNil: [ interCycleDelay delayDuration: millisecondsToWait ].
+ interCycleDelay wait ].
- (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.!