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

[Benjamin Fallenstein <b.fallenstein@xxxxxx>]

Tuomas Lukka schrieb:
> 
> > > 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.

Lucky me that I didn't actually have time to take care of that yet. :)
Well, your objections are absolutely true. An even more important
prevented arrangement would be interpolating between two windows, which
would be really nice once we can show two text streams at once and
tunnel text between them -- it should flow from one of the windows into
the other at some point.

It's really a case where hierarchies just do not work.

As for the multiline flob sets, I've found a way to work around them for
now, so there are more important things on my to-do list...

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

Good idea. Problem: how to get the depth right. We want to be able to
say "I'd like a subflobset at depth 7," then place elements in that
subflobset with depths ranging from 5 to 15, then have them drawn after
everything of depth 8 and before everything of depth 6 in the master flobset.

> 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...

I think it would limit us too much if the hard rasters would remain the
only ones which can repeat cells. If you create complex structures with
many "paradoxical" connections, e.g. tables with their columns sorted,
you basicly cannot use vanishing right now, but it would be nice to be
able to use it. Grid views with soft rasters, too.

To me, not repeating a cell when you encounter it a second time is a
special mode because it only works with *very few* of all conceivable
structures. Granted, lists and trees are what we're using now mainly,
but tables and networks (trees where nodes can have more than one
parent) are almost equally important. And we do not want to get locked
up in plain old Euclidean tables because we cannot view others.

So even while I see that most cells will be shown only once, and thus
this should be the efficient case, I think it would be totally wrong to
build a model in which a cell *can* only be shown once and adding a few
exceptions to that. That would lock us up because it would render more
complex structures unusable. 

Well, stdlinks doesn't do its job right with repeated cells, so we do
need a solution for that. Maybe saving in the flobs what they're
supposed to be connected to?

> 2) the SpanFlobs overlapping this span in this flobset

Right, that would be nice.

> 3) flobs corresponding to given cell anywhere
> 
> Hmm? We need to hash this out a little more.

I'm actually not sure of anything right now. :o/ This will probably
require a lot more attempts until we have a more or less generally
usable system.

> 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...

Yep. I'd also like up and down go to the next and previous line, which
is a similar problem...

- Benja