Re: iterator resolution




This is largely for future referenece after the bulk of
the code is working and you want to think about optimizations.

It looks like you have lots of areas which you can shave 
places of the size.  For example, in FrooTkxtSegment you
most likly will not need char_counts and byte counts more
that 64k.  If it is larger just split the segment in the 
middle.  This will save at least 10% on text with very small 
segements while costing less than 0.01% when you need to do a split.

Similar goes for the iterator type.  Also I would recommend just
switching to  "gpointer dumb[size]" for the iterator definition
rather than try to match it up.  All that matter is the size of
the declared iterator is large than the real iterator.  
(Also easily verified with a #if statement)

You may be able to make similar gains by changing the FrooTkxtLineData
height and width to shorts.  How many lines of text would
you need to have 64k pixels??  

Overall the implementation looks great.  You are efficiently using
the iterators to make for short clean internal implementations for
cursor functions.   Definitely a nice abstraction.

--Karl



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]