One thing that makes Morphic slower than MVC is that it does
less pixel caching. In MVC, all the system windows cache a one-bit
deep copy of their bits by default, which makes it really fast to
repaint the world. Another difference is that when you move or
resize a window in MVC, you just get a rectangle as feedback,
whereas in Morphic the window contents are laid out and re-drawn
on every frame. Dan Ingalls created a preferences that causes
the MVC outline-only behavior when moving and resizing system
windows. This helps a lot on slower machines. Finally, text
and list scrolling in MVC is done more incrementally (by blt-ing
up or down part of the frame and only re-drawing the newly
revealed information. This approach doesn't quite work in
morphic because some other morph, possibly animating (like
the Alice bunny), could be in front of your window. Thus,
you can't rely on the bits on the Display being "all yours".
Optimized scrolling could, of course, be done using an
offscreen buffer, but we simply never got around to doing
it. (If anyone tries this, be sure to only keep a buffer
for the active window pane to save memory.)

But from a later message in this thread, I think the real
reason that Morphic may be slow on a WinCE device has to
do with the interaction between the Squeak VM and the OS's
power management policy. A typical assumption is that
if the user hasn't touched the pen to the screen for a
certain period of time, then it is okay to slow down the
processor. I'm not sure of the policy details under WinCE,
but what may happen is that when you call the GetNextEvent()
function the OS takes a short nap before it returns. That
would explain why Sensor>>primMousePt seems to be taking
half the time in the MessageTally results.

An interesting test is to make a "BouncingAtomsMorph".
Then you can see graphically if and when the processor
starts to slow down. With that running, try evaluating:

  1 to: 1000000 do: [:i | "noop"]

versus:

  1 to: 100000 do: [:i | Sensor buttons]

If the atoms slow down more in the latter case, it
is probably because the OS is napping when asked
for events. (Note: The Squeak VM keeps checking for
input events even while executing a tight loop, such
as the first expression, in order to know if the user
hits the interrupt key. However it doesn't ask as
often as it does when running the UI, which asks
for inputs every cycle.)

I'll be interested to hear the results of these
experiments on a WinCE device...

Incidentally, I've been using Squeak on the Sharp iCruise.
This is a truely amazing Squeak machine. The display packs
full VGA screen into 4 inches diagonal, and it is razor sharp.
It support 16 bit color, so you can use Squeaks transparency
and the full palette of colors. Plus it has a camera that
Yoshiki Ohshima says supports resolutions up to 1024x768.
Performance is pretty good--about 1/10th of my (fast) 292
MHz G3. (I.e., it is similar to my old Mac 8100.) It would
be nice if it had sound, perhaps, and more RAM, but I'm
willing to give up a LOT for that fabulous screen.

	-- John