[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Progress of text system
From: |
Fred Kiefer |
Subject: |
Progress of text system |
Date: |
Mon, 17 Feb 2003 01:27:35 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020903 |
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
- Progress of text system,
Fred Kiefer <=
- Re: Progress of text system, Alexander Malmberg, 2003/02/16
- Re: Progress of text system, Alexander Malmberg, 2003/02/17
- Re: Progress of text system, Richard Frith-Macdonald, 2003/02/23
- Re: Progress of text system, Alexander Malmberg, 2003/02/23
- Re: Progress of text system, Fred Kiefer, 2003/02/24