pcplantdb

[Bear Kaufmann <bear@ursine-design.com>]

> > ...This method is getting me only 7 FPS on a 1Ghz
> > G4 :-(, other methods with worse layout got me up to around 21 for
> > this graph.  I hear that the Mac Flash player isn't as fast as other
> > systems though. I'd like to know what others get on their system (FPS
> > & OS/CPU Stats).
>
> > Check it out here: http://permaculture.info/test/richClient.php
>
> Just ran the GBI for a minute or two.
> Waaayyyy too much overhead for appropriate technology systems ("used 
> computers") like mine.
>
> Test results after letting it just sit and do its thing for a minute:
>
> FPS: 1
> OpCount: 961
> Tension: 6.46 (this varied a bit when I clicked on/dragged stuff but 
> seemed to re-stabilize at around 6.3-4something if I left the app alone 
> for a bit)
>  
Yes. Yes. and Yes. It's really quite intensive. This is really a brute 
force method. For each node it must compute the repulsiveness of all the 
other nodes. So those computations are #_of_nodes^2, plus spring 
calculations etc. I played with a number of methods that trimmed down 
the operation count, or altered the laws of physics, but they all 
generated less readable graphs. But not to worry. This is horribly brute 
force, and there are methods to optimize the comps (breaking the 
particles into quad trees, then computing the sum forces for each node 
in the quad tree, then only applying only those forces. The other 
graphing app uses this. It's a bit of code to implement, so I haven't 
done it yet.

I was also working out a different layout method in my head today, which 
would primarily deal with forces acting on the springs and locally 
connected nodes only, which would also cut the computation a lot.

> IBM ThinkPad 570E with P3 500 MHz, 320MB RAM, running Debian GNU/linux 
> r3.1 (sarge) and Mozilla 1.7.8 browser with Flash Player 7.
>
> Slows down even typing this e-mail noticeably when the GBI is running.
> After about 30 sec. of the GBI running my CPU fan kicks on (normally 
> never runs on these cool tropical winter evenings), and stays on until 
> about 15-20 sec. after I close the page.
> It's obviously the most computation-intensive code I've probably ever 
> run on this machine, aside from maybe a few GIMP image-editing 
> transforms (but they only take a handful or two of seconds so hard to tell).
>  
>
> Initially I have no idea what this widget is supposed to be 
> showing/telling/teaching me or how it relates to the plant information 
> in the textual DB or anything else for that matter.
>  
This is a relationship viewer. So currently we're lacking in a large 
amount of relational information. This becomes more useful as we add in 
RDF triple support.
The graph on there is one I created the XML for a while ago, so I just 
used it to test the system. It shows the related uses of a set of 
Optunia species. I think the uses and other simple data fields would 
provide some data now.

I'd see this type of view as part of a guild creation system, showing 
the food web between plants. Part of the ontology I was working on was 
to support those input/output (produces, consumes/consumed by) definitions.
So for example, a user would define the environmental conditions the 
arrangement will be in, which cuts down the result set to viable number 
of species. The user defines a set of outputs and/or inputs they want 
the guild to produce/use.
If the user wants honey, given x conditions, and wants to produce edible 
beans too, the system can help select and show optimal linkages.

There's only a minimal UI as this point. Consider it proof of 
non-optimized concept.

> There are a bunch of words in boxes connected by lines floating around 
> and I can click on a box and drag it somewhere and then everything sort 
> of rearranges itself but I'm not sure why or how and everything seems to 
> go back more or less where it was.
> After playing with it for a minute or two (no more, can't afford to 
> toast this CPU ;-) and knowing what we're hoping to do with this sort of 
> thing I can make some fair guesses as to what's going on.
> So I assume this is purely a dev prototype of a possible GBI platform 
> and not intended to be user-friendly yet.
>  
Bingo. :-) Alpha, way alpha.

> I suppose it might be OK on high-end machines.
> Definitely not accessible technology though.
>
> On the plus side whatever has to load over the wire loads very fast even 
> via dialup.  Heck, a decent JPEG image that size would probably take 
> longer to load.  Good job on that, however you did it.
>  
Thanks for noticing that up side. :-)
Yeah, this is only about an 8K swf. That's about one small low-quality 
60x50 pix image.

It'll take some optimizations for sure, but I wanted to show yall what I 
was working on.

Cheers,
Bear