On Mar 12, 2010, at 10:22 PM, Michael Ash wrote:
>> You're right; the specific call that's causing the worst speed issues is
>> returning a property typed with this structure:
>>
>> typedef struct { int32_t x, y; } IntegerPoint;
>>
>> It's not necessarily feasible to switch this to an NSPoint; it means digging
>> up every point in the code that relies on signed 32-bit integer math and
>> doing manual typecasting (or calling lround()) away from CGFloat. If there's
>> no way to cheat KVO into doing this sanely, I'll resign myself to it, but I
>> kinda hope there's something a little less annoying.
>>
>> (It's even more annoying because it *was* an NSPoint in a much earlier
>> iteration of the code and I changed it because it simplified the code in two
>> dozen places, and because the property in question is integer and doesn't
>> need the slower floating-point instructions to manipulate it.)
> Implement +automaticallyNotifiesObserversForKey: to return NO for that
> key, then call will/didChangeValueForKey: yourself in the setter. That
> will avoid the expensive automatic KVO machinery, while allowing you
> to leave everything else untouched.
The key is already manually notified, but when I re-ran Instruments to
double-check my results... Well, sigh. As people often seem to do with such
things, I was misinterpreting what it was telling me. The CPU time's actually
in -[NSView setNeedsDisplay:] for some reason. Sorry for the noise.
-- Gwynne
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
