Richard Frith-Macdonald <richard <at> tiptree.demon.co.uk> writes:
> (...) > Maybe it's worth re-introducing the optimisation to avoid locking > when not using threads, but that's tricky to get right (especially if > there is any possibility of the threading mode changing while an > animation is in progress). You can not change the mode while the animation is running. You can call [setAnimationBlockingMode:] at any time but you need to stop then restart the animation to actually change the mode. (I dont know how it works with Cocoa) > Is the locking really a major overhead, Dont know (did not test) but i read somewhere (Apple ?) it is. That's why i added these simple tests (a local variable is fast). *** I think i now remember why i use one ivar _and_ one local var. The local var can not be changed unless a C-riminal used too many _NSANIMATION_LOCK/UNLOCK ;-) but _isThreaded can ! This ivar is reset in the animation thread just before it ends. If the main thread calls a method, and then the animation stops BEFORE the method returns, then _isTheraded is set to NO, but _gs_isLocked is still YES. So [unlock] is called as it should be. This does not happen frequently but it may happen. I remember i spent hours on the thread mode. Not an easy task. So Nicola idea seems to be the best solution :-) Unless you are in a hurry, i will try (and fix?) during the next week-end. And add some comments/explanations around these macros ;-) Xavier _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev