Re: [Fenfire-dev] Re: Reimplementing the structure view with lobs

[Benja Fallenstein]

On Fri, 18 Feb 2005 20:56:43 +0200 (EET), Matti Katila
<address@hidden> wrote:
> On Fri, 18 Feb 2005, Benja Fallenstein wrote:
> > I've been thinking about this too; perhaps the key is to do the
> > optimization we discussed when I was in jkl last fall, about having
> > some system so that we do not need to create different Lob objects for
> > everything we show on the screen.
> 
> How about the TreeLob? Did you finished it?

Not really; IIRC I made a partial demo, but I never implemented the
full functionality I wanted.

> It has recursive manner for
> child things as would this structure lob do.

That's not the issue. It's not being recursive that makes this
difficult. It's the number of objects being created. TreeBox computes
a layout and then stays basically the same for a relatively long time.
StructureView changes every time the user presses a cursor key. This
creates many, many objects & gc overhead, which would make the system
unusably slow.

(Update:) In our discussion on IRC, you said that we could have a
StructureLob which stores the whole tree of nodes and links to be
rendered. This could indeed be made fast enough. But again we wouldn't
use the 'recursive lobs' stuff of TreeBox to fill StructureLob; we'd
still have to have normal code going through the graph and putting the
hierarchy into StructureLob.

(Also, as mentioned on IRC we can save some by only re-generating when
the user moves left/right; rotation doesn't need to create a new
StructureLob.)

It seems like a nice way to implement things. I won't do it myself any
time soon I think -- the current code works and I want to go forward
and implement new features :-) -- but if you want to do it, it sounds
fine.

> Layout objects have a manner to have everything ready before rendering.
> Therefore we could not easily use vob scene to pick up the structure
> points. But, only the inner lob knows where the structure points are.
> Otoh, it's ok to know the exact structure for layout objects but not
> actually the way it looks on screen.

Right; we can ask the SpatialView. Like,

     SpatialView.getStructurePoints(node);

-- if 'node' is on a canvas, then this would return all nodes on the
canvas, including 'node' (structure point == a node shown in a spatial
context, which we can connect buoys to).

> Let's assume we can do the previous tray like structure lob. How to make
> it fast enought to change between scenes? We could use couple of them and
> interpolate between them. I think this is trivial(I'm assuming that it's
> trivial or it's impossible) if we don't show spatial views' buoys that are
> started from ring 1+n buoys.

Sorry, I don't understand what you mean in this paragraph. :-/ I don't
understand what speed problem you're referring to here.

> > I think we should first get this demo ready before starting to work on
> > that, what do you think?
> 
> I don't see a reason for it. But I see more potential possibilities
> to use layout objects when can do it gloriously :)

I was talking about the big optimization thing which might take a lot
of time. I still don't see an important reason to work on this before
the demo is ready, because it doesn't add any features, but as I said,
if you like to do it, I'm fine with that ;-)

- Benja