Re: Progress of text system

[Richard Frith-Macdonald]

On Wednesday, February 19, 2003, at 10:03  am, Fred Kiefer wrote:

> Hi Alexander,
>
> you did include some of the needed layout reuse by now. I think this 
> is still on the wrong basis, so I will have to explain my point in 
> more detail. I was hoping that Richard would step in on this, as he 
> knows a lot more than me on the layout mechanism.

Sorry ... I just haven't had a chance to look through the new layout 
system, so I can't comment on the changes.

> According to the Apple documentation glyph handling should be quite 
> different. There is some unnamed object that generates glyphs, I would 
> see this as located in the backend for GNUstep, and inserts them into 
> a datastructure of the NSLayoutManager that Apple calls glyph stream. 
> This stream behaves like one big array, but should be implemented 
> differently for efficency reasons.

Yes ... the glyph stream is essential to get any decent performance in 
the long run.

> There used to be an implementation for this in GNUstep done by Richard.

I didn't know it had been removed ... yes the implementation was one 
based on quite a complex design that Nicola and I hammered out,
The complexity was due to the need for decent performance on large 
files, and was mostly to do with ensuring that the runs of glyphs
were safely segmented and managed so that sections of the glyph stream 
could be updated without having to regenerate all the rest.
I never got it completely working/integrated onto the layout system 
though, because the layout system did not correctly use the
glyph methods and was hard coded to assume than a unicode character was 
the same thing as a glyph.

> Glyphs are generate into this stream as soon as they are needed. The 
> glyph generator is a somewhat magic devices as it is able to store all 
> the information on font and character into 32 bits and does so very 
> efficently. I don't have the slightest idea how this can be done.
> On top of this glyph stream there is the breaking of glyphs into 
> fragments. This gets done by the NSTypesetter or a subclass. You are 
> right that this class is not very clear in the Aplle documentation and 
> that we may implement it differently without doing much harm.
> Now when the user changes the text it is neccessary to regenerate the 
> glyphs for the changed characters, but for the rest of the document 
> only the layout fragments may need regeneration not the glyphs.



> > 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.
>
> Wrong, the glyph generation, be it in the backend or where ever, 
> should use the public method on NSLayoutManager to store glyphs, 
> [insertGlyph:atGlyphIndex:characterIndex:] to name it.

Yes. The layout system *NEEDS* to use these methods to decouple 
characters from glyphs.
Without them it's not possible to get really advanced text handling (eg 
ligatures) and it's difficult to get good performance (you'd need to 
implement an alternative mechanism for keeping track of which glyphs 
need redrawing .... so you might as well implement glyph storage 
anyway).

> > > 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.
>
> I again dare to disagree. The layout mechanism is not there for its 
> own beauty, it servers the purpose of displaying and editing text. 
> Currently even with your latest optimizations (which help a lot when 
> editing the end of a text) it is to slow to be actually usable. If we 
> could make a new release of GNUstep based on this, we would offend all 
> the users of for example Mail.app, that need the layout mechanism a 
> lot.

I'm guessing, but  performance problems are likely to be  down to -
1. lack of line fragment layout optimsation.
2. lack of glyph storage optimisation
3. inefficient backend rendering