stéphane ducasse wrote:
Hi gunther
I would not switch from dolphin to morphic, just for morphic. But it depends what you are doing.
Morphic deserves a massive clean (may be coming back to pre etoy would be a good move).
Hi
(sorry for interfering)
Maybe also interesting: I do not know how these things worked in early Macs, but they had their own tricks to speed up rendering of windows and graphical elements.
http://www.folklore.org/StoryView.py?project=Macintosh&story=I_Still_Rem...
I do not really understand how it was realized, how should `drawOn:' work more effectively so that it heeds a given clipping region, but they apparently knew how to draw overlapping things fast.
(I have never neither worked nor programmed a Mac so I am not familiar with those mechanisms)
I only know that also in my morphs' onDraw: method I completely ignore the fact how much of it will be actually visible. I do not know how this could be handled conveniently (without breaking my head in investigating what parts of the morphs will visible and which will be out of sight). Now my (and surely many other morphs) simply draw everything. This is the case of PlotMorph2 as well.
When Morph was only 300 methods. Now the problem is that people with the know how will not do it. Also the concurrency model of morphic is not really good.
Stef
Long time ago someone liked the idea of Eveline http://map1.squeakfoundation.org/sm/package/1a0f534c-423b-4cfa-a0d5-17a428ec... (but I do not use it actively now) Maybe its "concurrency" model offered by mechanisms Entity after:schedule: Entity after:schedule:with: Entity after:schedule:with:with: Entity after:schedule:with:with:with: Entity after:schedule:withAll: Some time before, someone http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-July/062155.html noted that these mechanisms could be used also for Morphic. You can see for example:
City beginCall
It is an "event handler". It, among other things, schedules new event with
self after: (randomGenerator negExp: meanTimeBetweenCallAttempts) schedule: #beginCall.
They could replace the Morph step Morph stepTime These scheduling (thanks to usage of the BidirectionaLinkedList) --- i.e. adding a new event to a calendar of events --- has constant time complexity. So there is no penalty. And they are little bit more general than simple stepping.
But I think that easier way how to make Morphic things clear would be to implement it from scratch. Utilization of traits could also heal some inherent problems of single inheritance, which caused bloating of the Morph class just because of two Morph subclasses in unrelated subtrees required to share the same method(s), there was no other way but put it to their common ancestor---Morph. Even though for lot of other subclasses those methods were useless. So Morph growed and growed.
And I agree that this could not be done if there is no skilled one dedicated full time working days and nights, months and years on this.
On 25 août 05, at 19:26, Günther Schmidt wrote:
Tim,
so, if the *right* people are working on it, Morphic can be made to go wooooosh?
I've been thinking of switching from Dolphin to Squeak for a couple of reasons, Morphic in particular, because I just can't see how you could do the things you can do in Morphic as easily in Dolphin.
There have been posts on this topic for some time now, so I guess it's something that resists fixing?
Well in short, I'm asking whether it's reasonable to presume that this issue will be resolved any time soon or rather not to depend on that?
Günther