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

[Tuomas Lukka <lukka@xxxxxxxxxx>]

On Sat, 25 Nov 2000, Benjamin Fallenstein wrote:

> 
> Tuomas Lukka wrote:
> > > Tuomas Lukka wrote:
> > > > On Fri, 24 Nov 2000, Benjamin Fallenstein wrote:
> > > > > FText change: bg and fg colors, parts which aren't cells, parts make
> > > > > actual flobs or rends (so that applitudes can subclass). This
> > > > > temporarily breaks nile -- sorry, I'll try to fix ASAP.
> > > >
> > > > I was thinking: to save memory trampling, maybe font and colors should be
> > > > parts of a style object that could be reused? Flyweight pattern.
> > >
> > > You sure that would really save so much? I mean, we're reusing colors
> > > and fonts right now, too, don't we? And a new object has some overhead
> > > of itself, too.
> > 
> > True - it depends on how many parts there are in ftext. In Java, the
> > overhead is something like 8 bytes per object.
> 
> So if we count four bytes per pointer, and three pointers (font and two
> colors -- no, four, fontmetrics), we have a save of 12 Bytes per part,

> minus 24 Bytes for each style object, minus (how much?) for the style
> class code. If you take into account each part still has to save at
> least a string, this doesn't seem to be much of a plus to me.

This means that it saves 12*n - 24 bytes where n is the times the style
object is reused.

There wouldn't be style code if it were just a struct so actually it would
be a save even with just 100 objects.

The more important save might actually be having less pointers around for
the garbage collector to worry about.

> When does it really pay off? When we have, like, ten thousand part
> objects in an ftext? I'm tempted to think if we really have to do that
> (deduct large text pieces from the structure instead of just the piece
> we draw on the screen at a single point), it would be better to use a
> completely different structure with a string buffer and handles into it
> describing the markup.

True. However, for nile I expect it to be in the order of hundreds of
FText parts per view.

> My idea for ftext was to bring short pieces in a common structure that
> can be translated into flobs by a single layouter for many different applitudes.
> 
> Am I missing something?

Not really. The question is whether we'll slowly keep putting more style
into FText, such as shadows for the text, underline, outline, etc.

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.

	Tuomas