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: Douglas Davidson <email@hidden>
- Date: Mon, 6 Feb 2006 15:38:53 -0800
On Jan 24, 2006, at 5:22 AM, Camillo Lugaresi wrote:
The problem is that deleting lines at the top invalidates the
layout for the entire text view, which makes things slow for long
logs, and in general causes undesirable CPU usage. I will implement
the obvious fix of deleting lines less often (eg let the buffer
grow to 1.1 times the desired maximum, and then clip off the extra
10% in one fell swoop). However, I'd like to solve this problem
more radically.
Clearly, when deleting whole lines at the top, the layout of the
rest of the text does not really need to be recalculated: it should
be sufficient to cache an offset from the old line positions, and
add it to the stored information whenever it is requested (the line
that was at ordinate 30 is now at 30-14, etc.).
My question is: is it possible and desirable to add such an
optimization by subclassing NSTextLayout, or in some other way? It
is unclear to me if that class is designed for subclassing, and to
what extent; before pursuing this solution, I would like to know if
it is a recommended approach or if I should instead write a fully
custom text view that does not use the Cocoa text system.
As it happens, NSLayoutManager already has an optimized relayout
algorithm for this sort of case. The conditions under which it can
be used are a little complicated, however, so what I would recommend
as a first step would be sampling the application under conditions
where it behaves badly, to see where the time is actually being
spent. That should tell you, among other things, whether layout is
actually the issue, and whether you are falling off the optimized
code path or not.
Douglas Davidson
_______________________________________________
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