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

[Benjamin Fallenstein <b.fallenstein@xxxxxx>]

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.

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.

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?

-b.