Hi Andrea, Aaron,

> "Andreas Raab" <Andreas.Raab at gmx.de> wrote:
> > Russel,
> > 
> > > I think that the problems are not so much with morphic as 
> > > such, but with the way the we are programming it - in particular
> > > treating morphs as things to be built and rebuilt constantly rather
> > > then live objects to be used and resused.
> > 
> > Can you say a little more about what you mean by this?!

Aaron's examples are right on the mark.  Consider menus: many
menus, including TheWorldMenu, are created from scratch when the event
is received, used, and then discarded.  On an iPaq there is a noticable
pause while the world menu is created then displayed.

This pause is one of the user interface issues which make people think
"morphic is slow".

My personal pda code has a main menu at the top of the screen which is
vital for moving between apps/pages.  Using the standard pattern of
create-on-event, there was a slit second pause after pressing the button
to get the menu; which gave an impression of sluggishness.  Now the
navigation bar keeps a cached copy of the menu, updating it offscreen as
necessary, and the only thing that happens when a mouse event is
received is that the menu is displayed.  This has reduced the delay from
annoying to almost imperceptible.

The point I guess I was trying to make is that since moving morphic from
its prototyping beginnings to a class and source code based world, we
seem to be constantly creating complex constucts of morphs in a step by
step basis from nothing, displaying the result, then discarding it. 
This seems inelegant, and unorganic, and on a machine like an iPaq,
slow.

Cheers,

Russell

> 
> I cannot speak definately for Russel, but this is what I took it to
> mean.  If it's not what he meant, I think it still may be relevant.
> 
> For instance, if you have a group of PIM apps that all happen to use a
> MonthMorph, cache that, in some class var or something.  Keep track of
> it somehow.  You could use it across apps, but that may cause problems
> when more than one is open.  
> 
> Another idea is to keep a default instance of the morph, and perhaps
> even the model (why not?) accessible from the class side.  Let's say we
> have a ContactsApp.  "ContactsApp open" opens this default instance
> being held onto by some class var.  The entire morph.  It would take up
> more space, but it would sure be faster to start up than having to build
> the morph from scratch again, and possible read in datafiles, &c.
> 
> A real world example from my work is the visualizer (employing the
> ever-so-rad PlotMorph) I wrote to look at ecology data.  Each plugin
> makes it's own plotmorphs, so when you switch plugins, it makes another
> 8 plotmorphs.  When you switch modes within the plugin, it creates
> another 8 plotmorphs.  each of those plotmorphs hold on to plenty of
> other objects and morphs.  Why not just have those 8 plotmorphs set
> aside always, and simple clear and add data?
> 
> In this case, it's being run on fast desktops, so speed hasn't been much
> of an issue.  But it is ugly, and I plan on re-writing it with a much
> more elegant way of doing plugins.
> 
> My example may suck, and I'm rambling as usual, but hopefully you get
> the picture...
> 
> Regards,
> Aaron