on 99-11-20 01.25, Dean_Swan at Mitel.COM at Dean_Swan at Mitel.COM wrote:

> I don't really understand these reports all that well, and would greatly
> appreciate it if somebody who does could explain them.  Does this point to an
> obvious place where the time is getting used up?
> 

There is one interesting item: the Sensor>>primMousePt primitive takes more
than half of the processing time in 3 invocations:

> 
> 
> 
> - 2318 tallies.
> 
> **Tree**
> 81.9 PasteUpMorph>>doOneCycle
> |73.9 PasteUpMorph>>doOneCycleNow
> |  |63.4 HandMorph>>processEvents
> |  |  |28.0 HandMorph>>handleEvent:
> |  |  |  |14.0 HandMorph>>handleMouseUp:
> |  |  |  |  |14.0  MenuItemMorph>>mouseUp:
> |  |  |  |  |  13.8 MenuMorph>>invokeItem:event:
> |  |  |  |  |    13.7 HandMorph>>newMorph
> |  |  |  |  |      7.2 HandMorph>>alphabeticalMorphMenu
> |  |  |  |  |        |3.8 MenuMorph>>add:target:selector:argument:
> |  |  |  |  |        |  3.8 MenuMorph>>add:target:selector:argumentList:
> |  |  |  |  |      3.2 MenuMorph>>add:target:selector:argument
> |  |  |  |  |        3.2 MenuMorph>>add:target:selector:argumentList:
> |  |  |  |8.3 HandMorph>>handleMouseDown:
> |  |  |  |  |7.9 PasteUpMorph>>mouseDown:
> |  |  |  |  |  7.9 HandMorph>>invokeMetaMenu:
> |  |  |  |  |    5.1 HandMorph>>invokeMenu:event:
> |  |  |  |  |      |5.1 MenuMorph>>popUpAt:event:
> |  |  |  |  |      |  5.1 MenuMorph>>popUpAt:forHand:
> |  |  |  |  |      |    3.5 MenuMorph(Morph)>>position:
> |  |  |  |  |      |      3.1 MenuMorph(Morph)>>changed
> |  |  |  |  |      |        3.1 MenuMorph(AlignmentMorph)>>fullBounds
> |  |  |  |  |      |         2.5 MenuMorph(AlignmentMorph)>>fixLayout
> |  |  |  |  |      |           2.4
> MenuMorph(AlignmentMorph)>>placeAndSize:at:padding:
> |  |  |  |  |    2.3 HandMorph>>buildWorldMenu
> |  |  |  |5.4 HandMorph>>handleMouseMove:
> |  |  |  |  2.7 HandMorph>>handleDragOver:

This seems like a long time for a mouse location primitive (75% more time
than for redrawing the screen):

> |  |  |17.5 InputSensor>>cursorPoint
> |  |  |  |17.5 InputSensor>>mousePoint

Here the same Sensor>>primMousePt primitive goes again (see
HandMorph>>processEvent source):

> |  |  |17.3 primitives


> |  |10.3 PasteUpMorph>>displayWorldSafely
> |  |  10.3 PasteUpMorph>>displayWorld
> |  |    7.8 PasteUpMorph>>drawInvalidAreasOn:
> |  |      7.3 MenuMorph>>fulDrawOn:
> |  |        7.1 MenuMorph(Morph)>>fullDrawOn:
> |  |          6.2 MenuMorph(Morph)>>drawSubmorphsOn:
> |  |            6.1 FormCanvas(Canvas)>>fullDrawMorph:
> |  |              4.7 FormCanvas(Canvas)>>fullDraw:
> |  |                4.7 MenuItemMorph(Morph)>>fullDrawOn:
> |  |                  4.4 FormCanvas(Canvas)>>drawMorph:
> |  |                    4.4 FormCanvas(Canvas)>>draw:
> |  |                      3.8 MenuItemMorph>>drawOn:
> |  |                        3.1 MenuItemMorph(StringMorph)>>drawOn:
> |  |                          3.1 FormCanvas>>text:bounds:font:color:
> |  |                            2.5 QuickPrint>>drawString:at:
> |8.0 PasteUpMorph>>interCyclePause:
> |  7.9 Delay>>wait
> |    7.8 primitives

And again (see HandMorph>>startMessageTally source):

> 17.2 primitives
> 

The first three here are this primMousePt primitive, thus accounting for
more than 17.2 x 3 percent of the time (deduct the Delay>>wait time):

> **Leaves**
> 17.5 InputSensor>>mousePoint
> 17.3 HandMorph>>processEvents
> 17.2 HandMorph>>startMessageTally
> 7.8 Delay>>wait
> 2.7 QuickPrint>>drawString:at:
> 

This is the old problem with the Win VM making delays in the primMousePt
primitive. Since CEs use taps instead of dragging, the heuristic not to
delay when a mouse button is down doesn't work properly. This suggests that
the code for the WinCE VM should be changed. The waits above seem much
longer than the stipulated 5ms VM delays, too, however.

Henrik

< = > .