Progress of text system

[Fred Kiefer]

Currently only the text system is delaying the release of the next
GNUstep version. My current impression is that this is by now stable
enough for a release, but there are still a few functionalities that
must be merged back in and the performance needs a big rework.

It is not that I did loose confidence in Alexanders changes. What he did 
do to NSTextView, NSTextStorage, and NSTextContainer is great. This is 
only true to a lesser extend for the layout manager changes. Here all 
the dynamic layout parts have been removed. What is left is very similar 
to the NSStringDrawing code, but without the specific optimisation. 
Instead it does include handling for multiple text containers and a bit 
for glyph generation (most of this will only come when we use the pango 
library, but the place to integrate it is now there). We should try to 
resurrect the optimisations that where there to reuse already created 
layout. At least for the case where the text container is rectangular 
shaped.

The missing parts that I would like to see are the proper ruler handling
in the layout manager, part of which used to be there and background
colour handling that still needs implementation (runs will need both the
foreground and the background colour). Both of this are rather simple tasks.

I also would like to see some cleanup in the current code and file
structure. For no aparent reason the old file NSTypesetter.h was
replaced with some new GSTypesetter files. Here we should switch back to
the old way, as this was closer to the Apple specification. If the
extension methods are needed here, we should move them to a GNUstep
category. Similar changes should be done to the layout manger files. The
current separation into GSLayoutManager and NSLayoutManager is more or
less arbitrary. We should merge those two files together again and
instead make sure that we separate out the GNUstep extensions into
a separate category. That way the GSLayoutManager_internal header file 
will no longer be needed and all further optimisation may be done in a 
single file. Also the distinction between OpenStep, MacOSX and GNUstep 
methods needs to be enforced again in the header files.

For the optimisation I made another measurement. Of course we know that
[invalidateLayoutForCharacterRange:isSoft:actualCharacterRange:] needs
to be reworked first (even the commented out code here wont do), but
this will mostly change the total amount of time spend on the layout
(hopefully in a drastic way, as it is still five to ten times slower 
than the old system, which never was fast) not so much the relative
distribution. Independend of this big change, which in my point of view
will see the revival of a lot of Richards code for the NSLayoutManager,
we could already look at what needs to be handled later on:

   %   cumulative   self              self     total
  time   seconds   seconds    calls  us/call  us/call  name
  42,50    116,41   116,41        0     0,00
_i_GSLayoutManager_layout_setLocation_forStartOfGlyphRange_
  23,36    180,40    63,99 80584031     0,79
GSLayoutManager_run_for_glyph_index
  10,33    208,68    28,28        0     0,00
_i_GSHorizontalTypesetter__layoutLineNewParagraph_
   5,17    222,83    14,15        0     0,00
_i_GSHorizontalTypesetter___cacheGlyphs_
   4,57    235,34    12,51        0     0,00
_i_GSLayoutManager_glyphs_glyphAtIndex_isValidIndex_
   3,82    245,79    10,45        0     0,00
_i_GSHorizontalTypesetter__fullJustifyLine__
   3,27    254,74     8,95        0     0,00
_i_NSFont__advancementForGlyph_
   3,15    263,36     8,62        0     0,00
_i_GSLayoutManager_glyphs_characterIndexForGlyphAtIndex_


This is the result of loading a moderate sized RTF file and typing into
it a bit. [setLocation:forStartOfGlyphRange:] uses such a big amount of
time, as it is allocating memory. Here some tricks could be used. As was
already done in the NSStringDrawing code each line fragment could
already have one run (optimising the common case) and if we need to
allocated more, we should do so in batches.
Another place where optimisation springs to mind is the way the current
text container and line fragment are searched in each method. We should
cache of each of this an index with the layout manager and first check
if the chached values are still valid for the current glyph index
updating the cache if not.

My proposition for the text system are in this order:
1) Merge into cleaner and simpler file structure
2) Reenable reuse of already computed layout structure
3) Further optimisation as listed.

If Alexander agrees on this I am willing to join in. If not I will try 
to be patiened and wait.

Cheers
Fred