I've been trying to figure out why stock 3.2g images take about 3 seconds to start processing events (you can see this most easily by watching Squeaky's eyes as you move the mouse, or by clicking on text and looking for the highlight/cursor).
With the same VM, the 3.0 images don't exhibit this delay.
I see the same delay if I turn sound off in the image.
Any suggestions? I don't really feel like using gdb today.
Platform: Linux, 3.2g-4811 image, VM from CVS.
I've been trying to figure out why stock 3.2g images take about 3 seconds to start processing events (you can see this most easily by watching Squeaky's eyes as you move the mouse, or by clicking on text and looking for the highlight/cursor).
With the same VM, the 3.0 images don't exhibit this delay.
I see the same delay if I turn sound off in the image.
Any suggestions? I don't really feel like using gdb today.
Mm you could put a print to transcript, or collect the ms clock somewhere in SystemDictionary>>processStartUpList:
which gets run really early at startup time.
Then collect some more ms clock values in EventSensor>>processEvent:
Which indicates when events start coming in from the VM.
mmm and maybe over in HandMorph>>generateMouseEvent:
to capture when Morphic thinks about processing it.
On Tuesday 02 April 2002 03:07 pm, John M McIntosh wrote:
I've been trying to figure out why stock 3.2g images take about 3 seconds to start processing events (you can see this most easily by watching Squeaky's eyes as you move the mouse, or by clicking on text and looking for the highlight/cursor).
With the same VM, the 3.0 images don't exhibit this delay.
I see the same delay if I turn sound off in the image.
Any suggestions? I don't really feel like using gdb today.
Mm you could put a print to transcript, or collect the ms clock somewhere in SystemDictionary>>processStartUpList:
Did that, and found the problem...
99.4% {3270ms} AutoStart class>>startUp
Most of that is here:
50.9% {1675ms} AutoStart class>>checkForUpdates |31.0% {1020ms} HTTPClient class>>determineIfRunningInBrowser | |31.0% {1020ms} StandardFileStream class>>isRunningAsBrowserPlugin | | 31.0% {1020ms} StandardFileStream>>waitBrowserReadyFor:ifFail: | | 31.0% {1020ms} Delay>>wait |19.9% {655ms} PasteUpMorph>>install | 19.9% {655ms} PasteUpMorph>>displayWorldSafely
and here:
48.5% {1596ms} AutoStart class>>checkForPluginUpdate 29.2% {961ms} HTTPClient class>>determineIfRunningInBrowser |29.2% {961ms} StandardFileStream class>>isRunningAsBrowserPlugin | 29.2% {961ms} StandardFileStream>>waitBrowserReadyFor:ifFail: | 29.2% {961ms} Delay>>wait 19.3% {635ms} PasteUpMorph>>install 18.7% {615ms} PasteUpMorph>>displayWorldSafely
So, some questions:
1. Why do we have to ask twice (spending a second each time) whether we're running in the browser when we have a global to record that fact?
2. Why do we call PasteUpMorph>>install twice (for 650msec each time)?
It looks like we could save about 1.5 seconds if we just did each once.
And then:
3. Isn't there a faster way (under Unix at least) to see if we're running in the browser environment? Like an environment variable or something?
Can't the plugin code set a global?
Oh yeah, and another annoying little thing about startup:
in CS 4293etoyUsers a line was added to ProjectLauncher>>startUp that does this:
Utilities authorName: nil.
So now every time I go to enter a preamble in a change set I have to enter my name again (the image used to save it). Though it doesn't reset my author initials.
Ned Konz wrote:
99.4% {3270ms} AutoStart class>>startUp
- Why do we have to ask twice (spending a second each time) whether we're running in the browser when we have a global to record that fact?
Actually we don't have to do that. You should be able to just remove it from check for checkForPluginUpdate.
checkForPluginUpdate | pluginVersion updateURL | HTTPClient isRunningInBrowser ifFalse: [^false]. pluginVersion _ AbstractLauncher extractParameters at: (Smalltalk platformName copyWithout: Character space) asUppercase ifAbsent: [^false]. updateURL _ AbstractLauncher extractParameters at: 'UPDATE_URL' ifAbsent: [^false]. ^SystemVersion check: pluginVersion andRequestPluginUpdate: updateURL
Let me know if this works for you!
Thanks!
Michael
squeak-dev@lists.squeakfoundation.org