Re: NSLayoutManager and best override point for temporary attributes
Re: NSLayoutManager and best override point for temporary attributes
- Subject: Re: NSLayoutManager and best override point for temporary attributes
- From: Keith Blount <email@hidden>
- Date: Fri, 2 Oct 2009 02:28:33 -0700 (PDT)
Many thanks for the reply, Martin, much appreciated. I'm testing on Snow Leopard (and in fact things have got significantly slower on Snow Leopard, it seems, for my particular case).
Previously I was using the shouldChangeTextInRange and textDidChange text view delegate methods to calculate the exact portion of text that had been added, and then my text view iterated through the changed text looking for specific custom attributes and applying temporary attributes to them. The main problem in that method seemed to be caused by removing temporary attributes rather than adding them (-removeTemporaryAttribute... seems to be very slow and use up a lot of CPU if called to often), so maybe I can optimise that.
Another idea that occurs to me following your text storage suggestion is that I could create a text storage subclass that actually knows about its layout manager and uses it to assign temporary attributes along with standard attributes, though I'm not so sure about that one.
I hadn't thought of how -temporaryAttributesAtIndex:... might be doing a lot of caching internally, though, but it does makes sense, and would explain why trying to add temporary attributes in an override of this is so inefficient.
I wish there was an easier way of doing this, something in the layout manager itself so that you could just tell the layout manager, "if the text has this attribute, use this temporary attribute". Something like:
- (void)setUsesTemporaryAttributeName:(NSString *)name forAttributeName:(NSString *)name options:(NSDictionary *)opt;
Oh well!
Thanks again and all the best,
Keith
--- On Thu, 10/1/09, Martin Wierschin <email@hidden> wrote:
> From: Martin Wierschin <email@hidden>
> Subject: Re: NSLayoutManager and best override point for temporary attributes
> To: "Keith Blount" <email@hidden>
> Cc: email@hidden
> Date: Thursday, October 1, 2009, 1:50 AM
> Hi Keith,
>
> > I have certain custom text attributes that are used in
> my NSTextStorage to which I would like to add temporary
> attributes via the NSLayoutManager.
>
> What version of OSX are you testing under? Under Leopard
> there's a bug in -[NSLayoutManager
> temporaryAttribute:atCharacterIndex:longestEffectiveRange:inRange:]
> that calculates effective ranges that are too short. For
> specific test cases this caused big inefficiencies in the
> text system. I believe this bug is fixed in Snow Leopard.
>
> > more recently I have taken to overriding
> NSLayoutManager's
> -temporaryAttributesAtCharacterIndex:effectiveRange:
>
> If this is too slow, then I'd look to using some kind of
> cache for your calculations. But really, NSLayoutManager's
> temporary attributes are already a cache; one likely to be
> specifically designed for high performance index/run access.
> I think your original idea of setting temporary attributes
> whenever text changes would be the most efficient.
>
> Perhaps you're recalculating too much, too often? I don't
> know the access patterns for temporary attributes, but I
> would guess they are only queried when associated text is
> displayed on screen. If that's the case, you could fix them
> up lazily, eg: whenever text changes just note down that the
> attributes are dirty in that range. Your temporary attribute
> methods in your NSLayoutManager subclass can then ensure
> that temporary attributes are not dirty before they are
> returned.
>
> If none of that is efficient enough, you could rig up a
> NSTextStorage subclass that has two sets of attributes: one
> set for private use and another derived set which only the
> layout system sees.
>
> Hopefully some of that helps,
>
> ~Martin
>
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden