[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: [zzdev] Re: [zzdev] Changing back others' changes
- To: Tuomas Lukka <lukka@xxxxxxxxxx>
- Subject: Re: [zzdev] Re: [zzdev] Changing back others' changes
- From: "B. Fallenstein" <b.fallenstein@xxxxxx>
- Date: Mon, 30 Apr 2001 23:36:27 +0200
- Cc: zzdev@xxxxxxxxxx
- References: <20010430123206.W23764@xxxxxxxxxxxxxx> <16630.988627772@xxxxxxxxxxxxx> <20010501001834.Y23764@xxxxxxxxxxxxxx>
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
> 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.