`just slow it`....
marcel at metaobject.com
Sat Feb 10 17:21:54 UTC 2001
> From: John.Maloney at disney.com
> Might this actually reflect problems with MacOS-X scheduling?
> Assuming that it works a bit like X on Unix (although I know
> the graphics display is more like DIsplay Postscript than X),
> then there could be a problem with the display manager process
> and the Squeak process fighting for CPU cycles.
No that's probably not it. MacOS-X doesn't use a separate display
process any longer. Although there is a window manager, that is only
responsible for backing-store management and moving windows around.
All the drawing is done within the calling process using Quartz.
Anyway, the problem doesn't seem to be drawing related at all, nor
related to not having enough cycles. It's mouse-clicks that are
problematic, even if the resulting action only causes minor immediate
drawing activity. Whereas non-mouse-click activities with lots of
redrawing aren't affected.
> In this case,
> increasing the inter-cycle pause time might actually help, since
> Squeak would relinquish more cycles to the display manager.
I've played with intercycle pause quite a bit for other reasons, but
that doesn't seem to affect this particular problem (except
> You might try running the standard Mac VM under Carbon and see
> if that makes any difference. If you have an old 2.8 (pre-events)
> image around, it would also be interesting to see how that runs
> under various VM's. I'd like to know if the problems are limited
> to a particular VM or image.
I'll have to re-enable the InputSensor support code.
> I'm assuming that you're not running some CPU hog application
> like an MP3 compressor while you're running Squeak, that power
> saving modes are disabled if this in on a laptop, etc.
You assume correctly on the first part. ;-) As to power savings,
yes, I am running on a laptop, and I can't be 100% sure that's not
affecting it because MacOS-X support for power-savings settings is
fairly rudimentary. However, it doesn't seem to make a difference
wether I'm connected to power (which turns off various measrues) or
not. Also, I don't recall having these problems before on the same
> I've been running many combinations of VM and image under
> Mac OS 8.1 on an older 292 MHz G3 laptop, and performance
> is basically fine. John Macintosh has been doing some tuning
> to get the last once of responsiveness out of it, but even
> the less optimum VM's don't have the problems you are seeing.
Oh, I don't really think it is a matter of tuning. MVC with the
same VM is fine, non-interactive Morphic performance, though not
stellar, is fine (Bouncing Atoms, for example). Non-click Morphic
performance (dragging a menu around) is also fine, though again
nothing to write home about. However, there is this nagging problem
> (Which sound awful!)
Yes! Once again, I first figured that it (obviously!) was my VM
that was misbehaving, but when I started tracing events, I found out
that they got from the VM to the image just fine, and also to morphic
(I logged events to the transcript with time-stamps at various
places). It was inside the morphic event code that I started seeing
serious delays, and even dropped (mouse-down/mouse-up) events.
My guess is that this code is making some implicit assumptions that
aren't necessarily true any more (3.0) and have effects that are
somehow triggered more reliably and/or magnified by the MacOS-X VM.
More information about the Squeak-dev