Re: [zzdev] Re: [zzdev] Changing back others' changes

["B. Fallenstein" <b.fallenstein@xxxxxx>]

Tuomas Lukka wrote:
> > Remember that for an average VanishingView with a linebreaking cell view,
> > that means some hundred
> > flobsets because a sceneflob contains a flobset. *That's* woefully
> > inefficient. (An earler version
> > of FTextCellView did that and I changed it because it was too slow.)
> 
> Maybe the right answer is to make *that* efficient...

In src/, if we implement the VobStore system discussed on IRC, sure. In
the old code, I don't think so: it would involve writing an alternative
to SceneFlob/FlobSet because it's using standard flobsets that makes
this inefficient.

> Hmm... I did the quickest fix but in thinking for the src/ implementation,
> I think that the basic VobSetVob should not be boxed - the subclasses
> should decide.

Well, if we go through with the VobStore system, I'd prefer if we would
ONLY box sub-vobsets (created by VobSet.create, so that they can be more
efficient than VobSetVobs); these sub-vobsets would then have a box
type, which may just draw nothing. This means all cells would actually
be drawn using a sub-vobset.

Hm, this doesn't help with rotation... or maybe it does: we could let
the BoxType do translation and, if it likes to, clipping or rotation. Or
we could use something VobSetVob-like, which then would not be boxed
(because boxes would only be applied to sub-vobsets). However, the first
option would be nicer: it would support inter-(sub-)vobset connections
more easily, and even more important, it would make lots of small
rotated things more efficient... and allow arbitrary cell content to be
rotated if desired.

> > Also note that the code *only* clips if a line is too long for the box. The
> > hope is that usually
> > they will not be, at least in long blocks of text (which is where the
> > sceneflob would be an
> > efficient alternative).
> 
> An alternative would be not to clip but to cut the string and draw
> a black rectangle.

I'm not following.

-b.