gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: problems compiling NSAnimation.m


From: Xavier Glattard
Subject: Re: problems compiling NSAnimation.m
Date: Thu, 10 May 2007 16:57:34 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

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










reply via email to

[Prev in Thread] Current Thread [Next in Thread]