The behavior of ioRelinquishProcessor... is *very* different on the
different platforms. On Windows, it suspends Squeak for either the given
time or until an input event is received. Thus, the patch should work fine
on Windows. On the Mac, the function simply calls ioProcessEvents() and does
not wait at all. Thus your incredible frame rate ;-)

  Andreas
--
+===== Andreas Raab ========= (andreasr at wdi.disney.com) ==+
| Walt Disney Imagineering        Phone: +1 818 544 5016  I
I Glendale, CA                    Fax:   +1 818 544 4544  I
+======< http://isgwww.cs.uni-magdeburg.de/~raab >========+


> ----------
> From: 	Mark Guzdial
> Reply To: 	squeak at cs.uiuc.edu
> Sent: 	Wednesday, May 19, 1999 10:37 AM
> To: 	squeak at cs.uiuc.edu
> Cc: 	recipient list not shown
> Subject: 	Re: patch to interCyclePause:
> 
> I just tried this on a G3 Powerbook (Mac), and it acted very differently
> than described.
> 
> Before I loaded the fix, the framerate stayed pretty constant no matter
> how
> much I moved the mouse -- about 10-12 ms.
> 
> After the fix, the frame rate jumped considerably -- like 800
> frames/second, with a 0-1 ms cycle time!  By moving the mouse around alot,
> I could get the cycle time to rise and frames/second to drop.
> 
> But the magnitude of the difference has me a bit worried that the VM
> assumptions  aren't nearly the same.  I didn't see anything that broke
> with
> using this fix.
> 
> Mark
> 
> >Andreas Rauss has pointed out a couple of times that the interCyclePause
> >routine in Morphic can cause mouse clicks to be lost.  Here is a patch
> >that causes the pauses to terminate early whenever the system mouse has
> >changed state--thus, it should mean it's harder for clicks to get lost.
> >At least, I think that's how it will work; VM authors might want to read
> >the patch and see if it's true for their VM.  (It seems to work fine on
> >the Unix VM).
> >
> >To see this in action, put up a FrameRateMorph (from the Demos section of
> >"new morph....").  Wiggle the mouse around, and the frame rate should
> drop
> >down pretty low.  Leave it still, and the rate should go up to 20.
> Before
> >the patch, the rate should stay at 10 normally and hardly ever go below
> >that no matter what you do.
> >
> >In addition to the smarter pausing, there is a second change to make the
> >calculation more accurate.  Before, I had noticed that when you set
> >MinCyclePause to 20 milliseconds, you actually got an average pause of
> >*10* milliseconds.  This fixes that.
> >
> >
> >Enjoy!  If this works for other people than me, maybe it should be stuck
> >into the main system.
> >
> >Lex
> >
> >
> >
> >
> >'From Squeak 2.4b of April 23, 1999 on 18 May 1999 at 6:14:49 pm'!
> >"Change Set:		betterPausing
> >Date:			18 May 1999
> >Author:			Lex Spoon
> >
> >Fixes two things in WorldMorph>>interactionPause:
> >
> >	1. The timing is fixed, so that all pauses take effect instead of
> >just every other pause.
> >
> >	2. Uses ioRelinquishProcessorForMicroseconds: instead of
> >Delay>>wait.  Thus, mouse events should interrupt the pause.
> >
> >"!
> >
> >
> >!WorldMorph methodsFor: 'interaction loop' stamp: 'ls 5/18/1999 18:12'!
> >interCyclePause: milliSecs
> >	"delay enough that the next interaction cycle won't happen too soon
> >after the original; thus, if all the system is doing is polling for
> >interaction, the overall CPU usage of Squeak will be low"
> >	| currentTime wait |
> >
> >	currentTime _ Time millisecondClockValue.
> >	lastCycleTime ifNotNil: [
> >		wait _ lastCycleTime + milliSecs - currentTime.
> >		wait > 0 ifTrue: [
> >			wait < milliSecs  "big waits happen after a
> snapshot"
> >				ifTrue: [ (ProcessorScheduler
> >relinquishProcessorForMicroseconds: wait*1000) ]. ]. ].
> >	lastCycleTime _ Time millisecondClockValue.! !
> 
> 
> --------------------------
> Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA
> 30332-0280
> (404) 894-5618 : Fax (404) 894-0673 : guzdial at cc.gatech.edu
> http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html
> 
>