Re: Progress of text system

[Alexander Malmberg]

Fred Kiefer wrote:
[snip]
> 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).

Using pango in a backend to handle this is one option. My plan is to use
freetype's opentype support (once it actually has any), but this isn't a
high priority at the moment.

> 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.

There isn't much point in trying to resurrect the old code, as the
structure of the new system is very different. Reuse of layout
information is an important optimization, though. I've implemented the
basics of this, so layout information for glyphs above a change will be
reused now. The interface for soft invalidation (effectively, reusing
layout information for glyphs below a change) has been worked out, and
I'm working on the implementation. I've also committed a bunch of minor
optimizations that should help performance with large amounts of text.

[snip]
> 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.

Neither NSTypesetter nor its concrete subclass was ever implemented
here. In fact, they can't be, because there isn't enough documentation
to figure out how they are supposed to work. These classes really are
for internal use, neither OpenStep nor OPENSTEP have them publically
available.

> 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.

There is nothing arbitrary about this split.

GSLayoutManager is a generic layout manager, capable of dealing with
arbitrary layouts (horizontal, vertical, mixed, or even more complex
stuff). GSLayoutManager is only a dumb storage class for layout; it has
little knowledge about the layout, and can't implement all the methods
that NSTextView requires. When you want to handle generic layouts (eg.
if you want a layout manager that lets you use vertical layouts in a
text view), you subclass GSLayoutManager to get all basic glyph and
layout handling (and impose constraints on the layout), implement the
methods that NSTextView requires, and subclass GSTypesetter to make a
typesetter that lays glyphs out according to your constraints.

NSLayoutManager is a layout manager that supports only heavily
constrained layouts (normal left->right layout with line frags strictly
arranged in lines, and lines strictly ordered vertically, etc.; a
detailed list can be found in NSLayoutManager.m, and includes a lot of
things ranging from trivial (but important for simplifications) ~"each
text container has at least one line frag", to more complex ~"layout is
affected by context only as far back as to the previous line"). Thanks
to these constraints, NSLayoutManager knows a lot about the layout, and
can implement all the methods that NSTextView requires. NSLayoutManager
should be compatible with OPENSTEP's NSLayoutManager (except for
"internal, do not call" methods), and will probably be compatible with
most of apple's extensions eventually.

Merging these classes would severely limit their usefulness. We need a
standard layout manager for text views (and its behavior matches what
OPENSTEP calls NSLayoutManager), so we would lose GSLayoutManager. This
would make any work on anything more exotic than standard left->right,
top->down layout practically impossible.

> 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.

This file would still contain internal details of the layout manager
that are needed by eg. glyph generators in -back, but that a user of
-gui should never see.

> Also the distinction between OpenStep, MacOSX and GNUstep
> methods needs to be enforced again in the header files.

True. I've marked methods, but I haven't added #ifdef:s around them yet.

> 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.

There are many things that can (and should) be optimized in the layout
process (and I have committed a bunch of these today), but I believe the
major speedups will come from reusing layout information. (As an
example, if automatic kerning is enabled with back-art, ~90% of layout
time is spent doing freetype kerning pair lookups, which makes
everything else fairly irrelevant.)

[snip optimization ideas]

I'm working on these and other optimizations.

> My proposition for the text system are in this order:
> 1) Merge into cleaner and simpler file structure

I think this would be a very bad idea.

> 2) Reenable reuse of already computed layout structure

This is important and partially implemented. I'm working on the final
parts.

> 3) Further optimisation as listed.

I consider proper behavior (in eg. typesetting and text view actions)
more important than this, but I'll try to work on these optimizations as
well.

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

Well, it seems that we disagree about the structure of the text system.
There are still things to work on that don't touch it, eg.:

- The ruler system is something I haven't started looking at yet.
- rtf parsing and producing (this is very important because text views
use rtf internally to copy and paste).
- Resolving the many behavior issues (stuff like: what should happen
when the user presses page-down? generally involves thinking a bit about
and writing a short blurb about how it should be handled (and why!) in
the wiki).
- Smart deletion and insertion only has stubs currently.

> Cheers
> Fred

- Alexander Malmberg