Re: Properties, Attributes and Retain+Autorelease
On 2011-06-29, at 21:50 , Quincey Morris wrote: You're looking for provable correctness. That's laudable, and will probably mean that you keep all of your fingers. But you'll still end up in the emergency room -- in your case it will be for a stress-induced ulcer. :) My university professor once said: If you write code that other people will or have to use and they are supposed to use it without having to read your source code first, implement every method/function in such a way as if everybody out there has only one goal: Breaking it! Either by feeding completely absurd input parameters to it or by calling your methods/functions any completely absurd order or combination you can ever think of. Excuse me for saying this, but I think this particular discussion has gone on too long. The discussion was going on for hardly 9 hours when you wrote that. You're not going to get any new answers to your questions, because there are no answers to give beyond what's already been said. Actually I think I didn't get answers to those questions, because nobody knew the answers and instead of arguing why the answers don't matter, people could have just admitted that they don't know the answers either. Anyway, I think I figured out those answers all by myself in the meantime. Kind regards, Markus ___ 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
Re: Properties, Attributes and Retain+Autorelease (SOLVED)
Since nobody was able to provide real answers to my questions, I wrote some
dummy code to find out as much about that issue as possible. Here are the
results:
Remember, I listed the following cases:
a) retain
b) retain, nonatomic
c) copy
d) copy, nonatomic
e) assign
f) assign, nonatomic
And I gave sample code for a) and b) already:
a) retain
- (id)value
{
id res;
[_magic_lock lock];
res = [value retain];
[_magic_lock unlock];
return [res autorelease];
}
- (void)setValue:(id)aNewValue
{
[_magic_lock lock];
if (aNewValue != value) {
[value release];
value = [aNewValue retain];
}
[_magic_lock unlock];
}
b) retain, nonatomic
- (id)value
{
return value;
}
- (void)setValue:(id)aNewValue
{
if (aNewValue != value) {
[value release];
value = [aNewValue retain];
}
}
As far as my testing goes, the sample code seems to be pretty close to what's
really going on, though Apple is probably doing all this stuff on a much lower
level, possibly highly optimized and thus much faster than the code above ever
could. Here's how the code for the other cases would look like:
c) copy
The getter equals case a)
- (void)setValue:(id)aNewValue
{
[_magic_lock lock];
if (aNewValue != value) {
[value release];
value = [aNewValue copy];
}
[_magic_lock unlock];
}
d) copy, nonatomic
The getter equals case b)
- (void)setValue:(id)aNewValue
{
if (aNewValue != value) {
[value release];
value = [aNewValue copy];
}
}
e) assign
- (id)value
{
id res;
[_magic_lock lock];
res = value;
[_magic_lock unlock];
return res;
}
- (void)setValue:(id)aNewValue
{
[_magic_lock lock];
value = aNewValue;
[_magic_lock unlock];
}
f) assign, nonatomic
- (id)value
{
return value;
}
- (void)setValue:(id)aNewValue
{
value = aNewValue;
}
Apple may optimize case e) to become case f) in case reading/writing value is
an atomic operation anyway, e.g. setting a 32 bit value on a 32 bit CPU is
guaranteed to be atomic already through the compiler. However, setting a 64 bit
value on a 32 bit CPU (or a 64 bit CPU running in 32 bit mode) is not atomic
for example, just like setting a 8/16 bit value on a 32/64 bit CPU may not be
atomic (this depends on CPU, e.g. some operations are atomic on Intel CPUs that
used to be not atomic on PPC CPUs).
Kind regards,
Markus___
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
Properties, Attributes and Retain+Autorelease
Unfortunately the documentation on properties is really inadequate since Apple
fails to provide pseudo-code for every possible attribute combination. E.g.
the nonatomic attribute has a couple of dangerous side effects that seem to be
unknown even to developers using properties for years. The documentation should
provide sample code for the following attribute combinations:
a) retain
b) retain, nonatomic
c) copy
d) copy, nonatomic
e) assign
f) assign, nonatomic
Let me show you which dangerous side effects I'm talking about by providing
sample code for the cases a) and b) as I would have implemented them:
a) retain
- (id)value
{
id res;
[_magic_lock lock];
res = [value retain];
[_magic_lock unlock];
return [res autorelease];
}
- (void)setValue:(id)aNewValue
{
[_magic_lock lock];
if (aNewValue != value) {
[value release];
value = [aNewValue retain];
}
[_magic_lock unlock];
}
b) retain, nonatomic
- (id)value
{
return value;
}
- (void)setValue:(id)aNewValue
{
if (aNewValue != value) {
[value release];
value = [aNewValue retain];
}
}
Okay, you can argue about the implementation details here, e.g. the if-clause
in the setter is optional, I could also implement a setter like this:
[aNewValue retain];
[value release];
value = aNewValue;
This will work fine, even if aNewValue equals value, but it causes an
unnecessary retain/release and those are certainly not the fastest operations,
since they will either involve locks (rather expensive) or at least atomic
operations (still somewhat expensive and have a negative impact on overall
system performance of multicore systems, since they might for example have to
block the CPU bus to guarantee atomic access across all cores and that means
other cores are not be able to access main memory during such an operation).
The code above already reveals a huge problem: When I read the terms atomic
and nonatomic, I certainly expect one to use a lock (or at least atomic
operations of some kind) and the other one not. This is no big surprise. What
is a big surprise though, is the fact that one version extends the lifetime of
an object beyond the lifetime of its owner, while the other one won't. This
has *NOTHING* to do with wether an operation is atomic or not!
E.g. consider the following code:
ObjectCreator oc = [[ObjectCreator alloc] init];
id value = [oc value];
[oc release];
[value someMethod];
In case a) this will work just fine, however in case b) this code might *CRASH*
my app! This is a fact not obvious to many developers. The nonatomic attribute
makes getters behave like getters of NSArray or NSDictionary, which do not
extend lifetime of returned objects beyond their own lifetime, while normal,
atomic getters do the retain+autorelease dance. This is something that should
be written on the very top of Apple's doc in bold letters with a font size of
18 pt.
Unfortunately a) and b) are the only obvious cases, already c) and d) are not
really explained in detail. One thing that seems obvious is c) and d) use
copy instead of retain in their setters. However, what about getters? Do
they use copy there as well? Do they use retain+autorelease? Do they just
return the values? Are the getters equal to the getters a) and b) for copy
properties?
Similar questions arise for e) and f). E.g. will e) return the values
retain+autorelease, even though the setters don't use retain? And how does
nonatomic make any difference for assign properties? Assigning a pointer is
guaranteed to be atomic anyway by the complier, at least for 32 bit pointers on
i386 architecture when using GCC. I guess the same holds true for 64 bit
pointers on x86_64 architecture (so I had to re-read the GCC specification to
ensure that fact). Is the nonatomic attribute ignored for assign properties?
These open questions are what drives me away of using properties, since when I
write my getter/setters myself, I know at least the answers to all those
questions and the answers will not change either (contrary to the answers for
properties, that might change whenever Apple releases a new Objective-C
language specification).
Kind regards,
Markus___
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
Re: Properties, Attributes and Retain+Autorelease
On 2011-06-29, at 13:58 , Fritz Anderson wrote: Apple may be (and probably is) using methods more primitive than retain/release/autorelease. It may (probably has, and very probably will) change the implementation between point releases of the operating system. This is absolutely obvious, but you are failing the point. I don't personally care how Apple really implements it, I just would like to see which code would pretty much lead to exactly the same behavior. That this code might be entirely different than the real code is of no importance to anyone, I guess. And of course using properties is in theory a good thing, since I bet most of them is implemented in plain-C, possible even some hand written assembly code, and thus certainly faster and more effective than any code you could ever write yourself using high level Objective-C. However I cannot use something correctly if there is no documentation of how it actually works. E.g. the question how nonatomic influences assign properties (if it does influence them at all!) is a critical and absolutely valid question, especially if it has similar *UNEXPECTED* side effects as it has for retain properties (and you cannot avoid assign properties entirely, otherwise you can get circular references and thus leaking memory). Kind regards, Markus___ 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
Re: Properties, Attributes and Retain+Autorelease
On 2011-06-29, at 18:09 , Matt Neuburg wrote: As I said then, Ownership is *never* something you are magically given. Since when do you have to be owner of an object to be allowed to interact with it? This contradicts pretty much everything Apple has ever documented about Cocoa/Obj-C. Following your reasoning, Apple has to re-design Cocoa and re-write all guides and sample code, since no method should ever return a retain+autorelease result, instead all code must always follow the (currently inexistent rule): An object returned by another object is only guaranteed to live as long as the object lives that returned it. To extend its lifetime you always have to retain the object. Right now this is only the case for collection classes and it is in fact *so special* that Apple *explicitly* points out this fact in their documentation. And to be honest, Apple only implemented them that way for performance reasons - if retain+autorelease was pretty much for free, I bet Apple had even used that for return values of collection classes; since that is what they do for pretty much all other classes. E.g. the description method of an object always returns a NSString that will for sure stay alive, even if you kill the object after calling description on it - I have never seen an implementation of description which hasn't. Nobody would seriously consider retaining this string. However, you are also missing my primary point: I have no problem with the fact that an object won't live longer than it's parent; this is just something that nonatomic doesn't tell me. Nonatomic tells me that the operation is not atomic, fine, but I don't expect it to influence object live duration; those are two completely different things not related to each other. Also it's pretty much funny how both answers I received so far concentrated on this remark, but none of them answered a single of the various questions I have asked in my mail (and *THOSE* were my primary points). Now that I have learned what nonatomic means to retain properties, it would be nice to know what nonatomic means to assign and copy properties for example. Kind regards, Markus___ 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
Re: Properties, Attributes and Retain+Autorelease
On 2011-06-29, at 18:09 , Matt Neuburg wrote:
As I said then, Ownership is *never* something you are magically given.
Actually I have to correct my previous statement, since it is incorrect. I said:
Following your reasoning, Apple has to re-design Cocoa and re-write all guides
and sample code, since no method should ever return a retain+autorelease
result, instead all code must always follow the (currently inexistent rule):
An object returned by another object is only guaranteed to live as long as the
object lives that returned it. To extend its lifetime you always have to retain
the object.
However, this is far from true. Even if the object stays alive and even if you
don't call a setter for this property (e.g. it might even be a readonly
property), any other call to the parent might cause it to release the previous
returned object. So I always would have to retain any object I received through
any method call you can think of before using it. Even if I just want to pass
it on I have to retain it:
id value = [someObject value];
[value retain];
[someOtherObject setValue:value];
[value release];
Why? How can I know that someOtherObject won't have a reference to someObject
and that calling setValue of someOtherObject won't make a call to someObject
which causes some object to release the value it returned before, without
someOtherObject having a chance to retain it? Since someOtherObject cannot know
from where it received the value and it certainly won't expect this value to
go away just because it calls some method of someObject. Does that make any
sense? If not, maybe with some more code. Assume that my code is only like that:
[someOtherObject setValue:[someObject value]];
Pretty typical code you find in millions of source files. However, now consider
someOtherObject has a reference to someObject and part of their implementation
will look like this:
// someObject
- (id)value
{
return value;
}
- (void)doSomething
{
// ...
[value release];
value = ...;
/ /...
}
// someOtherObject
- (void)setValue:(id)aValue
{
[someObject doSomething];
if (value == aValue) return;
[value release];
value = [aValue retain]; // --- BANG, CRASH
}
So I would have in fact to always retain any value before doing anything with
it, even when I just want to pass it on! Think about it.
Kind regards,
Markus___
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
Re: Properties, Attributes and Retain+Autorelease
On 2011-06-29, at 19:17 , Kyle Sluder wrote:
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmPractical.html%23//apple_ref/doc/uid/TP40004447-1000922-BABBFBGJ
Yes, it talks about certain*exceptions*, and you are right, one of them is in
fact destroying the parent, so I'm wiling to accept that you must not rely upon
an object to stay alive longer than its parent. However, have you also read
the top paragraph?
Cocoa’s ownership policy specifies that received objects should typically
remain valid throughout the scope of the calling method. It should also be
possible to return a received object from the current scope without fear of it
being released. It should not matter to your application that the getter method
of an object returns a cached instance variable or a computed value. What
matters is that the object remains valid for the time you need it.
This principle is violated by a getter returning an object that is not
retain+autorelease, since even without destroying the parent the returned
object might go away. As pointed out in my other mail:
[someOtherObject setValue:[someObject value]];
// someObject
- (id)value
{
return value;
}
- (void)doSomething
{
// ...
[value release];
value = ...;
/ /...
}
// someOtherObject
- (void)setValue:(id)aValue
{
[someObject doSomething];
if (value == aValue) return;
[value release];
value = [aValue retain]; // --- BANG, CRASH
}
It violates the policy stated above, even though this is *no collection* class
and the parent has *not* been released. Neither of the two exception cases
mentioned on the liked page above has been met!
If that was allowed, one would have to write code like this:
id value = [someObject value];
[value retain];
[someOtherObject setValue:value];
[value release];
And nobody seriously writes such code.
Kind regards,
Markus___
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
Re: Properties, Attributes and Retain+Autorelease
On 2011-06-29, at 20:08 , Matt Neuburg wrote: On Jun 29, 2011, at 10:39 AM, Markus Hanauska wrote: If that was allowed, one would have to write code like this: id value = [someObject value]; [value retain]; [someOtherObject setValue:value]; [value release]; That's silly. You didn't release someObject this time, so now there's no need to worry about the lifetime of value. That's assuming that setValue of someOtherObject is not doing anything in the system (call a method, maybe posting a notification, altering a singleton or a global variable, etc.) which may cause value to be released... and I can not guarantee so, unless I know for sure that value is either retained or at least retain+autorelease. Since almost all Cocoa objects from Apple will return value retain+autorelease, this can indeed not happen, but hey, it wasn't me claiming it's perfectly okay that nonatomic getters don't return objects retain+autorelease and that this will not break anything, because it's totally okay if objects you don't own unexpectedly cease to live. I posted code that showed how this can easily happen, haven't you read it? Shall I make a compilable project for you, so you can see it crashing yourself? I personally think a getter should always return objects retain+autorelease and that no matter if it is atomic or not. This is certainly not the best thing performance-wise, but it is the safest way to return values in a complex system where you don't know which implications simple method calls really have under the hood. E.g. you can skip the retain+autorelease dance when you use private objects in your own framework that you don't expose to the public or properties not visible outside your framework (they are just for internal use), but for all methods you are going to expose only the retain+autorelease dance guarantees safety. Which brings me back to my original questions, e.g. whether an assign property returns values retain+autorelease when atomic and not when nonatomic... or does it always return the value not retain+autorelease since assign properties ignore the nonatomic flag anyway, since there is nothing to be done, they are atomic anyway by definition. Kind regards, Markus___ 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
Running at Logout (like Technical Note TN2228, but for logout)
I would like to write a little tool that syncs my preference files of various apps between different Macs. I have a couple of applications that have plenty of complicated settings and I would like to keep these settings always in sync between several different Macs. The problem is that I cannot use network synchronization, since one of those Macs is not always connected to a network and I would like this sync to work even without an active network connection. The solution: I will use an USB stick for it. The idea is pretty simple: Prior to logging in, I plug in the USB stick, then I log into the Mac using my user account. The pref files are copied from the USB stick to my home folder (~/Library/Preferences). When I log out, the pref files are copied from my home folder back to the USB stick. The USB stick thus always contains the latest versions of these files. There is no need to merge settings, since I will always only be logged in to one of those Macs at all times and the settings of this Mac are always the new desired default settings. Ideally the tool will also support situations, where the USB stick is currently not plugged in during login or logout and prompt me for plugging it in before continuing the login/logout process. There is just one big problem with that idea: The applications that read/write those pref files are login items, that means they will start immediately after logging in and keep running until I log out again. To make sure the apps start with the right prefs, I must replace the prefs prior to starting these apps (after login, but prior to login items) and since the sync can take a couple of seconds, I'd need a way to temporarily suspend the login until my tool is done. The same problem applies to logout: Since pref files are written asynchronously and thus the app might modify the pref file again right before quitting, my tool has to wait till the app has really quit before syncing the pref files, otherwise it may not sync the most up-to-date version. Thus my tool must run after all apps were quit, but prior to the real logout and of course it has to suspend the logout until it is done with copying files. My first idea was to write a launchd agent, but I'm afraid such an agent is started way too late on login and terminated way too early on logout, so I dropped this idea pretty soon. The next idea was to write a launchd daemon that runs as root (thus having access to all user home directories), but this approach will not work, because in case of a file vault or a remote home, the daemon won't have access to the user home when the user is not currently logged in. So for the login problem the real solution seems to be an **authorization plug-in**. I can place it after the user home has been mounted, so it will have access to the user home files, but it can also delay the login process for as long as necessary (waiting for USB stick to be plugged-in, waiting for sync to finish or waiting for user to cancel sync), thus the sync will have finished for sure once the login items are being started. From what I've read so far regarding these plugins, this approach really seems to be the way to go. The remaining problem is how to sync back on logout? There seems to be no way to write a authorization plug-in that runs on logout. Basically I need code that runs after all user processes have been terminated, but before the user home is unmounted, and that also can delay the logout process until all operations have been finished. Any way to do this? A rather crude approach would be to start a launchd agent right after the login has succeeded that has an ExitTimeOut of 0, so launchd will send it a SIGTERM on logout, but it will never send it a SIGKILL. The agent could now catch the SIGTERM, wait for all other user processes to terminate (except for launchd and itself of course) and then start the sync process. The main problem with that approach: If my tool has a bug and somehow never terminates (nor crashes), the whole logout blocks forever. Also I'm not sure if the agent would be allowed to still start other processes (e.g. maybe a helper tool to display UI, since I'm not sure if I would like this agent to be Cocoa app) and if the agent is not canceling the whole logout by waiting too long. Maybe this is not a good idea after all, but the only one I could come up with :-( Apple seems to have a better way to run lougout tasks, e.g. remote home synchronization, file vault compaction, etc. Any ideas are pretty much welcome. Thanks. Regards, Markus___ 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
Re: Smooth OpenGL animation possible, even if main thread blocks?
On Friday, 2010-06-25, at 21:18, vincent habchi wrote: As far as my experience goes, it was perfectly possible to update a CALayer from a background thread as long as you make this thread run its own runloop. That's what I did some time ago before reverting to the classical method for the sake of complexity. Possible or Allowed? ;-) It is also possible to use Cocoa UI objects from different threads; at least if you do it carefully, you might get away with that. However, I doubt this is really allowed and if it stops working, Apple will say We told you not to Considering that the future of processing is more and more cores (virtual or physical ones), it is pretty unfortunate that Cocoa is so little thread-safe and that UI is still often bound to main thread. Apple seems to believe that UI operations and event handlers are always very light weight and that everything else is a calculation task you can perform on a background thread. This only holds true for very simply applications and shuffling data around between threads is far from zero cost. -- Markus Hanauska ___ 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
Re: Smooth OpenGL animation possible, even if main thread blocks?
On Monday, 2010-06-28, at 14:43, vincent habchi wrote: Possible or Allowed? ;-) Both, I think. If I am not mistaken, it was some Apple guy (David Duncan?) who pointed out the role of the runloop. I therefore take for granted that, if it is not allowed, it must at least be tolerated. What does work, but I doubt it is allowed, is to directly call 'display' on the CALayer. Apple says you should not call this method directly, but so far it seems to work and has not crashed... on the other hand it might crash if the CALayer is destroyed on the main thread asynchronously (that can be avoided, though, by making sure the other thread stops first, before the CALayer is ever destroyed). Another issue is that it might cause refreshes of the CALayer, even thought the layer is not even visible right now (e.g. the whole Window is minimized); but that could be solvable, too, though I'm not sure how (querying UI properties of elements from a thread other than main is definitely not thread-safe). -- Markus Hanauska ___ 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
Smooth OpenGL animation possible, even if main thread blocks?
Let me shortly describe the current situation: We have a window and inside this window is a layer-hosting NSView. This view is supposed to permanently display a never ending OpenGL animation. Why did we use CALayers for that? For no specific reason, it just sounded like starting with 10.5 CALayers is the way to go and maybe one day we also want to make use of CALayer animation capabilities, so why not? So we did as Apple told us: Subclass CAOpenGLLayer and override the appropriate methods. To not overload the main thread, all calculations are performed on a background thread, that updates all necessary parameters of our CALayer, when done, it waits some time (to avoid the animation is running too fast) and finally updates the content of the CALayer by calling setNeedsDisplay on main thread (performSelectorOnMainThread). This works pretty well, we are quite happy with the results. Now to our problem: If the main thread is blocking for a short while or temporarily not running its runloop, which can happen for various reasons, the animation starts to stutter. It doesn't even have to block for a very long amount of time, it only needs to block longer than the time difference between two animation updates. This is by far not long enough to get a spinning mouse cursor for this application. We try to do everything asynchronously and never block the main thread for one millisecond longer than absolutely necessary, but nonetheless only reacting to all kind of user input can sometimes make the animation less smooth than we would like it to be. Of course that is expected, because without the main loop performing the CALayer update, no update will happen and when the next update is performed, any number of animation frames might have been skipped. What we want is that this animation is always smooth, no matter how busy the main thread might be. Even if it blocks for a whole second it should be smooth, at least as long as the CPU has enough resources to keep the animation updating on time (otherwise there is no way to avoid that frames are skipped, but if the system is at its limits, that is absolutely okay). With normal NSViews, you can also perform updates from background threads, as far as I understand the documentation, by directly locking focus from the background thread (lockFocusIfCanDraw), directly drawing to the view and unlocking focus again. There seems no way to lock focus for a CALayer and no way to paint into and thus update the content of a CALayer from any other thread, but the main thread. So what are we supposed to do? Is there something I'm overlooking here or should we maybe stop using CALayers and instead use NSOpenGLView or maybe even manage our own OpenGL Context, render into a background buffer (e.g. some kind of image) and then directly paint this image from within the background thread into the view whenever we want to? If so, what image is most effective for such a task? NSImage, CGImage, CIImage? Any advise is highly appreciated. -- Markus Hanauska ___ 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
Re: Memory management on returning nil in init
On Monday, 2010-06-21, at 16:43, Eiko Bleicher wrote:
-(id) initWithBool:(BOOL)ok
{
if (self = [super init])
{
if (!ok) {
return nil; // Point of interest
}
}
return self;
}
Does this code leak?
According to my understanding of Cocoa, it does leak. You should call [self
release], as otherwise the just created object (the object has already been
created by [CLASS alloc] when init is being called) is never released
otherwise. Further no other object that [super init] might create is released.
My inits usually look like this:
- (id)initWithBool:(BOOL)ok
{
self = [super init];
if (self) {
if (!ok) {
[self release];
self = nil;
}
}
return self;
}
--
Markus Hanauska
___
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
Why is actually kAuthorizationEnvironmentIcon often not working for 10.4?
Hi everyone! Has anyone here ever found out why kAuthorizationEnvironmentIcon for authorization requests sometimes works and sometimes not? It's not the image format or anything. I thought it has to do with whether the path has spaces inside or not, but that's not it either. It seems to fail as soon as the path to the file is beyond a certain length. The code always works if I reference any image within /tmp, as this is a very short path. But if I reference the very same file in the app bundle, it fails (and I can use this C-string and pass it to open command on command line and the image will open in preview just fine). Has nothing to do with the image format either, like I said, the very same image works when copied to /tmp and using a path to there. -- Best Regards, Markus Hanauska ___ 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 [EMAIL PROTECTED]
