> But I agree that this all (meaning the contortions to get updates onto the > main thread) seems like too much flash and not enough bang. The easiest way > would be to dispatch the original update code in blocks onto the main thread > asynchronously, thus serializing them and generating KVO notifications > safely.
I thought of that at first, to solve the uncommitted CA transactions issues. But the syntax is ugly. And I didn’t want to post blocks from all over the place to the main thread (I have 100+ NSTextfields with number formatters updated every second… meaning as many blocks...). So I went for the updateUI solution, which is cleaner: It only requires me to duplicate instance variables. At this point, I would like to add that instance variables (and their UI–bound property counterpart) are mostly double with a few int, so they aren’t retained objects subjects to leaks. > When I think about it in those terms, it’s clear (to me, at least) that the > *real* problem is one of coalescing a potentially large number of updates > over time. In other words, this thread is really about premature optimization > and its ugly consequences. The issue, to me, is to get my app to run for a few days without crashing. The only way I have to make it work, currently, is by not updating the UI. This is a shame considering the time I spent arranging all those textfields in a nice fashion to make it easily readable despite the large number of displayed values (and also, IB gets really really slow with that many controls on a view, making the design part a real pain). _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
