[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSTextView actions
Re: NSTextView actions
Sun, 02 Feb 2003 18:18:56 +0100
Fred Kiefer wrote:
> Hi Alexander,
> you are making great progress with the new text system. Still there is a
> lot to do and test. Have you ever used the Ink example to display any
> bigger RTF files?
I've been using TextEdit to test. Jeff Teunissen converted the .nib:s to
.gorm:s and wrote the GNUmakefile, but otherwise the code is unchanged
from the OS version, which makes it a very nice test case.
> There you can see that the new code to format text is
> a lot (factor 10 I would say) slower than the old one, which never was
> very fast. As this was the biggest problem with the old code all of us
> should have a go on performance as soon as you consider the new text
> system as feature complete. I did some measurements (see my old mail on
> profiling) and it looks like GSLayoutManager_run_for_glyph_index uses up
> most of the time. Skip lists are normally a rather fast, so there might
> be another problem here. Another place for improvements would be the
> linear seach inside of the line fragments (and text containers, but this
> to a lesser extend).
Yes, editing is very slow at the moment. The glyph handling should be
very efficient, so I don't think it's directly responsible for the slow
behavior. Relayout after changes is probably the big bottleneck, since
currently all layout is redone from scratch every time there is a
change. I expect performance to increase a _lot_ once soft invalidation
of layout is in place (basically, it would only do layout for the lines
at the change and reuse layout information for the rest of the text).
In general, the handling of layout information is naive since I wasn't
sure what the best way to handle it was. If it's too slow even with soft
invalidation, it may be necessary to rewrite it, or even add hacks to
make the common case fast. Anyway, I'd like to get correctness first.
> Also some of your cation methods look plain wrong to me. For the ligatur
> and kering methods you don't call beginEdit and EndEdit on the text
> storage. That way the layout manager would not hear about that changes.
> We don't use this methods in the moment, but still it should be
> corrected. I don't want to touch any code here myself, as this might
> disturb your work.
As I understand it (see eg.
), edit notification is done automatically by the editing primitives,
and -beginEditing and -endEditing are just for delaying this so you
collect several edits before notifying. Thus, if you only make one
change (ie. one call), there's no need to call them. The current
implementation of GSTextStorage behaves this way, so the action methods
- Alexander Malmberg