Re: [Gzigzag-commits] gzigzag/Java/flob FTextLayouter.zob SimpleTextView.zob

[Tuomas Lukka <lukka@xxxxxxxxxx>]

> > But you're right: we shouldn't be solving performance problems until we
> > encounter them. Currently, the most important one would be VanishingView,
> > when depth is set to be large. That's quite slow and I suspect a part of
> > it is because of the FlobSet's liberal use of Vectors. But that would need
> > actual profiling before doing anything to make sure that that is really
> > the place where the trouble is. Because drawing also is significant there.
> 
> Well, my FlobSet-as-Flob draft gets rid of that vector use, using
> pointered lists instead. Unfortunately, I'm not having enough time to
> make it work right now. Sometime in the next few weeks...

Actually, now I'm again unsure as to whether flobset-as-flob is reasonable.
The reason is that it makes difficult or prevents some arrangements, e.g.
different flobsets where the depths interleave.

What I'm thinking of now is a recursive flobset API where you can ask it for
a subflobset, etc.

The biggest problem, I guess, is defining exactly what kinds of searches we
want to put in there for different things.

I'd say:

1) definitely "(nearest) flob for this cell in this flobset", returning
   exactly one flob

	- what to do about several flobs for a cell? In this model,
	  that would only happen for loops in e.g. the hard rasters.
	  The dimension-showing cells would be in a different flobset
	  so they wouldn't be a problem.
	- maybe the hard rasters shouldn't rely on stdlinks but draw the
	  connections themselves? That would actually make some sense...

2) the SpanFlobs overlapping this span in this flobset

3) flobs corresponding to given cell anywhere

Hmm? We need to hash this out a little more.

I'm thinking right now mostly of several nile streams being shown at once, which
is a more difficult model than we have now, as e.g. page up and page down would
require finding out what the lowest displayed part of this stream is...

	Tuomas