Re: Optimizing text layout in a log view: should I subclass NSLayoutManager?
Re: Optimizing text layout in a log view: should I subclass NSLayoutManager?
- Subject: Re: Optimizing text layout in a log view: should I subclass NSLayoutManager?
- From: Camillo Lugaresi <email@hidden>
- Date: Sat, 28 Jan 2006 11:35:13 +0100
On 27/gen/06, at 00:54, Martin wrote:
Clearly, when deleting whole lines at the top, the layout of the rest
of the text does not really need to be recalculated
This is of course true, but that doesn't mean NSLayoutManager
implements such an optimization. To be honest I'm surprised that it
doesn't, since I've seen it optimize away other kinds of
incremental changes.
Indeed. And unfortunately, even if it was added, I'd still need a
workaround for the current verision of the OS.
My question is: is it possible and desirable to add such an
optimization by subclassing NSTextLayout, or in some other way?
I think subclassing NSLayoutManager to do such a thing would be
hard (and potentially hazardous) work. There's no public API for
doing this kind of thing, so you'd have to write some tricky
overrides, call private methods, etc.
I was thinking of overriding
textStorage:edited:range:changeInLength:invalidatedRange: and the
various line fragment rect methods. What puzzles me is that
NSLayoutManager does not seem to be designed for subclassing, and yet
they document methods such as setLocation:forStartOfGlyphRange: and
say : "This method is used by the layout mechanism; you should never
invoke it directly." If I'm not supposed to call it, and I'm not
supposed to override it, why are they telling me about it? It feels
as if they started out wanting to support third-party extension, and
then dropped the idea.
Probably the safest and easiest solution in your case is to divide
your log into groups of several hundred (thousand?) lines. Each
block would have its own NSLayoutManager instance. Your custom view
would then draw these blocks by stacking them on top of one
another. When the log becomes too full just pop the oldest block off.
The only potential problem here is user interaction. For instance,
if you want to allow the user to select/copy log lines you will
have issues at the block boundaries.
That should be a small issue, and if I'm writing a custom view I'll
have to reimplement selection anyway. At this point, I wonder if I
should break the storage in paragraphs (since that's what the program
deals with at a higher level), lay them out separately using
NSATSTypesetter, and stack them.
I hope this helps,
It sure does, thank you.
Camillo
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden