Part of the slowdown may be the cost of getting bits to the screen via the normal WinCE interface. Yoshiki Ohshima found that using the windows games API gave a huge speedup in display update speed. Of course, that is only part of the reason that Morphic feels slow, and you may already be using a VM with Yoshiki's display code. Another possible source of sluggishness is floating point operations, which must be emulated on the StrongARM. Finally--and this is real stab in the dark-- there may be an unexpected interaction between Windows CE and event processing. You might see if an old 2.7 or 2.8 image feels any faster when running Morphic.
We've been fairly impressed with the raw computational power of the iPaq, but we're not using Morphic on it. Nor are we doing Squeak development on the iPaq. We develop on a desktop or laptop and just move the image over to the iPaq for testing.
-- John
At 2:40 AM -0400 5/11/01, Noel J. Bergman wrote:
The point isn't that the iPAQ is slow (heck, I have emulators on iPAQ that run faster than the original hardware) ... the point is that Morphic on the iPAQ is so slow as to be unusable. Multi-second response times when moving windows or popping up menus, etc. I am much happier with the performance of MVC.
Part of the slowdown may be the cost of getting bits to the screen via the normal WinCE interface. Yoshiki Ohshima found that using the windows games API gave a huge speedup in display update speed.
As you surmised, I am already using Ohshima-san's VM. And I concur with you that the raw computational power of the iPAQ is impressive. So those should not be the problem. MVC responds acceptably, but Morphic is a dog. I have not yet tried an image with Ned Konz's Morphic optimizations, although if they only yield a 28% improvement, that won't be a big help.
Another possible source of sluggishness is floating point operations
Is Morphic more dependent upon floating point than MVC?
there may be an unexpected interaction between Windows CE and event
processing.
That would impact Morphic but not MVC?
I don't have an old image available ... I just started playing with Squeak recently, and Ned Konz was kind enough to help me get directly onto Squeak 3.
Might I ask what your image prep method looks like, which generates for the iPAQ? I'm using one that is derived from both Fisher's and Ohshima's, and learned from each one.
--- Noel
On Samstag, Mai 12, 2001, at 04:14 Uhr, Noel J. Bergman wrote:
there may be an unexpected interaction between Windows CE and event
processing.
That would impact Morphic but not MVC?
Very possible. I saw some pretty nasty interactions between Morphic + the new event handling code and MacOS-X's event system that madea 233 MHz G3 pretty much unusable in Morphic, though everything was fine in MVC.
Marcel
Marcel,
That's very interesting. Do you recall what the interactions were, and the solutions?
--- Noel
-----Original Message----- From: Marcel Weiher [mailto:marcel@metaobject.com]
there may be an unexpected interaction between Windows CE and event processing.
That would impact Morphic but not MVC?
Very possible. I saw some pretty nasty interactions between Morphic + the new event handling code and MacOS-X's event system that made a 233 MHz G3 pretty much unusable in Morphic, though everything was fine in MVC.
Much has been written in this forum of, on one hand, the "imperative of," and on the other, the "anathema of" formulating a committee-qua-committee, defined not by the program, but by some communally reached statement of purpose. I noted that it is foolish to insist upon choosing between a community-driven artifact and an artifact-driven community, noting that they are inherently co-dependent notions, neither well-defined without the other.
Nothing in this colloquy has led me to reconsider that view. I am more convinced than ever that a community defined by some theoretical purpose rather than an underlying program is doomed to irrelevance, and that an ossified artifact program to define a community is likewise doomed. The looser the structure of the community, the better and more flexible it will be. As I was reading some recent criticism of Cas Sunstein's "REPUBLIC.COM," the following 1992 quote by Dave Clark of MIT caught my eye:
"We reject kings, presidents and voting. We believe in: rough consensus and running code."
squeak-dev@lists.squeakfoundation.org
-
Andrew C. Greenberg -
John.Maloney＠disney.com -
Marcel Weiher -
Noel J. Bergman