Re: Debugging memory leak in NSURLSession with ARC

[Graham Cox]

> On 2 Jan 2015, at 1:46 pm, Roland King  wrote:
> 
> Having a handler block which refers to self is not in and of itself a 
> problem, very many blocks implicitly do. The block retains self, however in 
> most cases something else retains the block and the self reference goes away 
> when the block is released. The problem usually comes when the handler block 
> which refers to self is also a property of the object, eg myObj.completion = 
> ^{ .. block referring to myobj }. Xcode normally warns you if you even get 
> close to doing that however. 

Right. Well, my block refers to self, but it's not a property of self. Quickly 
trying it with a weak version of self shows no change of behaviour regarding 
memory usage, so I guess that was a red herring.

Just to be sure, I have:

...[owns]...NSURLSession...[owns]...NSURLSessionDataTask...[owns]...completion
 block...[refers to]...

I don't think this amounts to a retain cycle, because when the session has 
finished the task, it will release it, and its block, and those references to 
self (my object) that it has.


> 
> If that's happening then allocations should show you are amassing whatever 
> objects those are and never releasing them, does it? Or you can be old skool 
> about it and NSLog() dealloc() to see if it's getting called.


What appears to be amassing are 132KB malloc'd blocks (by the hundreds). These 
are created by HTTPNetStreamInfo::_readStreamClientCallBack(__CFReadStream*, 
unsigned long), down in CFNetwork. The stack trace is:

   0 libsystem_malloc.dylib malloc_zone_malloc
   1 libsystem_malloc.dylib malloc
   2 CFNetwork HTTPNetStreamInfo::_readStreamClientCallBack(__CFReadStream*, 
unsigned long)
   3 CFNetwork 
CFNetworkReadStream::_readStreamClientCallBackCallBack(__CFReadStream*, 
unsigned long, void*)
   4 CoreFoundation _signalEventSync
   5 CoreFoundation _cfstream_shared_signalEventSync
   6 CoreFoundation __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
   7 CoreFoundation __CFRunLoopDoSources0
   8 CoreFoundation __CFRunLoopRun
   9 CoreFoundation CFRunLoopRunSpecific
  10 CFNetwork +[NSURLConnection(Loader) _resourceLoadLoop:]
  11 Foundation __NSThread__main__
  12 libsystem_pthread.dylib _pthread_body
  13 libsystem_pthread.dylib _pthread_start
  14 libsystem_pthread.dylib thread_start


Which actually doesn't directly link it to anything in my code, though I think 
it's safe to say it's something set up by NSURLSession or NSURLSessionDataTask, 
which I do create in my code.

BUT, and this is a big but, I'm not sure if I'm interpreting Allocations 
correctly. I have it set to "created and persistent", and graphing these blocks 
shows a very close corrlation between them and the overall memory usage 
profile, so my interpretation is that these are predominantly responsible for 
the memory usage of my app. However, the shape of the graph does show that a 
lot of these blocks are freed, but not all, leading to the gradual increase in 
baseline allocation.

Here's the rough outline of the code I'm using to run the 
NSURLSessionDataTasks. This is a method of , and it is called once 
when there is data to begin downloading, and runs itself as long as there are 
items in the queue to be processed.

- (BOOL)dequeueNextChunk
{
// removes next URL from the chunks queue and starts it asynchronously 
downloading as a session. Returns YES if a chunk was dequeued, NO if not (queue 
empty).

XVMediaChunk* chunk = [queuedChunkURLs firstObject];

if( chunk )
{
// dequeue

[queuedChunkURLs removeObjectAtIndex:0];

// schedule download and start it

[[self.session dataTaskWithURL:chunk.url 
completionHandler:^(NSData *data, NSURLResponse *response, NSError *error)
{
NSHTTPURLResponse* httpResponse = 
(NSHTTPURLResponse*)response;

if( httpResponse.statusCode == 200 )
{
// got a valid response. If it's a valid chunk 
add the data to the chunk object and pass it along to the next step.

if([httpResponse.MIMEType 
isEqualToString:@"video/mp2t"])
{
chunk.data = data;

[self processVideoChunk:chunk];

// and schedule the next chunk in the 
queue

[self 
performSelectorOnMainThread:@selector(dequeueNextChunk) withObject:nil 
waitUntilDone:NO];
}
}
else
{
  

Re: Debugging memory leak in NSURLSession with ARC

[Clark S. Cox III]

> On Jan 1, 2015, at 18:26, Graham Cox  wrote:
> 
> 
>> On 2 Jan 2015, at 12:48 pm, Quincey Morris 
>>  wrote:
>> 
>>  That usually means the block and the ‘self’ it captured mutually refer 
>> to each other. I’m betting this is what’s wrong in your case.
>> 
>> 
> 
> 
> Quincey, thanks for your lengthy and well-thought-out reply (as usual) :)
> 
> I think you've hit the nail straight on the head (as usual), with the 
> block/self problem. It's one I knew about before, but had forgotten again in 
> my excitement at getting the code running. The question is what to do about 
> it.
> 
> My handler block refers to 'self' quite extensively - it calls other methods 
> of self and also refers to properties such as self.delegate. I'm not quite 
> sure how I can rework it not to refer to self. Maybe I just need to not use 
> the completion block approach and use a delegate callback instead. I need to 
> go away and think about this... thanks for the slap about the head.
> 
> —Graham

One of the first things I define in any ARC codebase I’m going to be working on 
is:

#define DECLARE_WEAK_SELF  __weak __typeof__(self) weak_self = self;
#define DECLARE_STRONG_SELF__strong __typeof__(weak_self) self = weak_self;

And I use it like so:

- (void)method {
DECLARE_WEAK_SELF

self.someBlock = ^{
DECLARE_STRONG_SELF;
//Use “self” as usual here
};

self.someOtherBlock = ^{
DECLARE_STRONG_SELF;
//Use “self” as usual here
};
}

-- 
Clark Smith Cox III
clarkc...@gmail.com



smime.p7s
Description: S/MIME cryptographic signature
___

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

Re: Debugging memory leak in NSURLSession with ARC

[Roland King]

> On 2 Jan 2015, at 10:52, Joar Wingfors  wrote:
> 
> 
>> On 1 jan 2015, at 18:22, Roland King  wrote:
>> 
>> +1 for all of this. I wouldn't call leaks an utter waste of time, but it 
>> really does only find pure retain cycles (which it then annotates very 
>> nicely) and not memory which is really is pinned by a real reference which 
>> is more often the case. Also, if you're using KVO anywhere, this tends to 
>> entirely defeat leaks even though KVO isn't a strong reference and shouldn't 
>> be treated like one, it is. That makes leaks less useful than it could be 
>> for me because I'm always KVO'ing something.   
> 
> 
> I don't think leaks would find cycles. I could be wrong, but I don't think 
> it's sophisticated enough to perform that additional level of analysis. I 
> think it only finds stuff that's truly referenced from nowhere else on the 
> heap. 
> 

Perhaps we're talking cross purposes because it definitely finds what I'm 
calling cycles, where object A references B strongly and B references A 
strongly (or a longer chain of objects which eventually forms an equivalent 
loop). If that loop of objects isn't strongly referenced by anything else and 
is thus 'leaked', leaks not only finds it but gives you a pretty diagram 
showing how all the objects are strongly referencing each other, with property 
names etc. 

IIRC that facility arrived the same year as ARC. It's occasionally useful. 



___

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

Re: Debugging memory leak in NSURLSession with ARC

[Joar Wingfors]

> On 1 jan 2015, at 18:22, Roland King  wrote:
> 
> +1 for all of this. I wouldn't call leaks an utter waste of time, but it 
> really does only find pure retain cycles (which it then annotates very 
> nicely) and not memory which is really is pinned by a real reference which is 
> more often the case. Also, if you're using KVO anywhere, this tends to 
> entirely defeat leaks even though KVO isn't a strong reference and shouldn't 
> be treated like one, it is. That makes leaks less useful than it could be for 
> me because I'm always KVO'ing something.   


I don't think leaks would find cycles. I could be wrong, but I don't think it's 
sophisticated enough to perform that additional level of analysis. I think it 
only finds stuff that's truly referenced from nowhere else on the heap. 


> There's an old blog by bbum which covered using generational analysis for 
> finding leaks which aren't leaks. Xcode has changed quite a lot since then 
> but some of the screens look quite similar even now. I routinely put my code 
> through this torture test, it's so easy to run and the results are often very 
> illuminating. 
> 
> http://www.friday.com/bbum/2010/10/17/when-is-a-leak-not-a-leak-using-heapshot-analysis-to-find-undesirable-memory-growth/


That functionality has since been integrated into Instruments, so it's easier 
to use. 

Joar



___

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

Re: Debugging memory leak in NSURLSession with ARC

[Joar Wingfors]

> On 1 jan 2015, at 18:26, Graham Cox  wrote:
> 
> 
>> On 2 Jan 2015, at 12:48 pm, Quincey Morris 
>>  wrote:
>> 
>>  That usually means the block and the ‘self’ it captured mutually refer 
>> to each other. I’m betting this is what’s wrong in your case.
>> 
>> 
> 
> 
> Quincey, thanks for your lengthy and well-thought-out reply (as usual) :)
> 
> I think you've hit the nail straight on the head (as usual), with the 
> block/self problem. It's one I knew about before, but had forgotten again in 
> my excitement at getting the code running. The question is what to do about 
> it.
> 
> My handler block refers to 'self' quite extensively - it calls other methods 
> of self and also refers to properties such as self.delegate. I'm not quite 
> sure how I can rework it not to refer to self. Maybe I just need to not use 
> the completion block approach and use a delegate callback instead. I need to 
> go away and think about this... thanks for the slap about the head.


You can always employ the weakself+strongself pattern:

__weak Foo *weakSelf = self;
AsyncBar(^{
Foo *strongSelf = weakSelf;
if (nil != strongSelf) {
[strongSelf doStuff];
// more stuff
}
});

That said, if an object is going away it's typically better to use explicit 
cleanup / teardown, than relying on __weak. Tear down bindings, KVO, timers, 
delayed runloop invocations, outstanding async work, etc. More direct, more 
predictable, easier to troubleshoot/debug. 

Joar


___

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

Re: Debugging memory leak in NSURLSession with ARC

[Roland King]

> 
> My handler block refers to 'self' quite extensively - it calls other methods 
> of self and also refers to properties such as self.delegate. I'm not quite 
> sure how I can rework it not to refer to self. Maybe I just need to not use 
> the completion block approach and use a delegate callback instead. I need to 
> go away and think about this... thanks for the slap about the head.
> 
> --Graham
> 
> 

Having a handler block which refers to self is not in and of itself a problem, 
very many blocks implicitly do. The block retains self, however in most cases 
something else retains the block and the self reference goes away when the 
block is released. The problem usually comes when the handler block which 
refers to self is also a property of the object, eg myObj.completion = ^{ .. 
block referring to myobj }. Xcode normally warns you if you even get close to 
doing that however. 

If that's happening then allocations should show you are amassing whatever 
objects those are and never releasing them, does it? Or you can be old skool 
about it and NSLog() dealloc() to see if it's getting called.

Two ways around block retain cycles are 

1) If the block is a property of the object, eg a callback block, when you've 
called the block, nil the property, break the cycle. 
2) The strong/weak dance. You make a weak pointer to self which is actually 
captured in the block, then in the block you assign it to a strong pointer, 
then check for nil, then use that pointer. 

MyObj __weak *weakSelf = self;

^{ 
MyObj *strongSelf = weakSelf;
if( strongSelf )
{
// do work using strongSelf explicitly
}
}



___

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

Re: Debugging memory leak in NSURLSession with ARC

[Graham Cox]

> On 2 Jan 2015, at 12:48 pm, Quincey Morris 
>  wrote:
> 
>  That usually means the block and the ‘self’ it captured mutually refer 
> to each other. I’m betting this is what’s wrong in your case.
> 
> 


Quincey, thanks for your lengthy and well-thought-out reply (as usual) :)

I think you've hit the nail straight on the head (as usual), with the 
block/self problem. It's one I knew about before, but had forgotten again in my 
excitement at getting the code running. The question is what to do about it.

My handler block refers to 'self' quite extensively - it calls other methods of 
self and also refers to properties such as self.delegate. I'm not quite sure 
how I can rework it not to refer to self. Maybe I just need to not use the 
completion block approach and use a delegate callback instead. I need to go 
away and think about this... thanks for the slap about the head.

--Graham





___

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

Re: Debugging memory leak in NSURLSession with ARC

[Roland King]

+1 for all of this. I wouldn't call leaks an utter waste of time, but it really 
does only find pure retain cycles (which it then annotates very nicely) and not 
memory which is really is pinned by a real reference which is more often the 
case. Also, if you're using KVO anywhere, this tends to entirely defeat leaks 
even though KVO isn't a strong reference and shouldn't be treated like one, it 
is. That makes leaks less useful than it could be for me because I'm always 
KVO'ing something.   

There's an old blog by bbum which covered using generational analysis for 
finding leaks which aren't leaks. Xcode has changed quite a lot since then but 
some of the screens look quite similar even now. I routinely put my code 
through this torture test, it's so easy to run and the results are often very 
illuminating. 

http://www.friday.com/bbum/2010/10/17/when-is-a-leak-not-a-leak-using-heapshot-analysis-to-find-undesirable-memory-growth/
 


I do remember there was a recent discussion on the dev forums about 
NSURLConnection 'leaking' in iOS8. It appears it wasn't actually leaking, but 
it did amass memory which it gave up in a delayed manner only when you stopped 
making requests. Again that's iOS, but I do wonder if the same code is in OSX 
and whether the same effect is there too. That discussion, which doesn't quite 
reach a conclusion, is here .. 
https://devforums.apple.com/message/1056669#1056669 



> On 2 Jan 2015, at 09:48, Quincey Morris  
> wrote:
> 
> On Jan 1, 2015, at 17:20 , Graham Cox  wrote:
>> 
>> I'm using Allocations, but I'm finding the volume of data a bit overwhelming.
>> 
>> As an aside, Leaks shows nothing at all. Does that mean I'm not actually 
>> leaking anything?
> 
> Forget Leaks, it’s an utter waste of time*. Use marked generations. The 
> persistent increase in each generation is your real “leak”.
> 
> — In code where things happen repeatedly in the background, it can be hard to 
> get your app into a quiescent state (in terms of allocations) so that you can 
> find a good place to mark a new generation in Instruments. You may have 
> temporarily add code to create and/or prolong such a quiescent state.
> 
> — It’s generally not useful to *start* by looking at the retain/release 
> history. You’ll find problem objects easily, but you won’t know where they 
> came from or why they didn’t get released.
> 
> — In the list of objects incrementally leaked in a generation**, look for the 
> ones that you actually created (either objects of your own classes, or 
> objects that were obviously created at a particular known place in your 
> code). Out of those objects, try to eliminate the ones that appear to be 
> “children” of others. 
> 
> — Ideally, you’ll find two sorta-kinda top-level objects remain. The 
> presumption is then that there’s a reference cycle between them. For example, 
> you might find that one is a window controller and the other is something in 
> your data model***. Or, you might find that one is a block, and the other is 
> whatever created the block.
> 
> — Audit the relevant source code. It’s often easiest and quickest to find the 
> cycle just by inspecting the declarations/blocks.
> 
> — Only if that goes nowhere is it time to start analyzing the retain/release 
> history of a generation in Instruments. By now, though, you should have a 
> vague idea of what you’re looking for.
> 
> — Start by getting Instruments to pair as many retains and releases as it can 
> automatically. 
> 
> — If that’s unproductive, start over and compare them all yourself. (But I 
> should add that I haven’t spent much time doing this in Yosemite yet. The UI 
> may be a bit different since Mavericks, and the auto-pairing may work a bit 
> differently, too.)
> 
> 
> ** Create multiple generations, and look not only at what was leaked in each 
> generation, but what’s repetitive in the pattern of leaks. Your real culprit 
> should produce an identical pattern every time. Leaks unique to a generation 
> aren’t what you’re looking for here. (I think this is the debugging 
> equivalent of the second derivative.)
> 
> *** That usually means a window delegate reference needs to be manually 
> nil’ed when the window closes, because we learned how to do bad memory 
> management in the bad old days.
> 
>  That usually means the block and the ‘self’ it captured mutually refer 
> to each other. I’m betting this is what’s wrong in your case.
> 
> * I should say, I’m not scorning Leaks. It’s just that experienced Obj-C 
> developers tend not to make the kinds of mistakes that Leaks can detect. 
> Experienced developers make other, better mistakes.
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator co

Re: Debugging memory leak in NSURLSession with ARC

[Cosmo]

A while back I had a similar sounding issue in an iOS project I was working on. 
The memory usage kept growing, although I could find no obvious culprits in my 
code after hours of exploration. My solution probably doesn’t pertain to you, 
but I thought I’d pass it along just in case it’s something you might have 
overlooked. 

I showed my project to another more experienced developer seeking help. He 
agreed with my assessment that there weren’t any apparent major problems with 
my code. But he discovered that I had left Zombies detection turned on in the 
project scheme settings (left on from exploring another issue some time back). 
So of course Instruments was showing me the memory that Zombies was holding 
onto. Turning off Zombies detection gave me a very steady memory usage pattern.

> On Jan 1, 2015, at 5:20 PM, Graham Cox  wrote:
> 
> I'm using Allocations, but I'm finding the volume of data a bit overwhelming.
> 
> As an aside, Leaks shows nothing at all. Does that mean I'm not actually 
> leaking anything?
> 
> What I'm seeing sort of agrees with expectations - the memory usage graph has 
> a broadly "sawtooth" waveform as each download task is created, builds up, is 
> processed and released. However the underlying memory usage continues to 
> climb, with the sawtooth on top. Breaking down the allocations shows that the 
> 132KB bufers are the vast majority of the allocations, but maybe my 
> interpretation that they're not being freed is wrong - they are listed but 
> maybe that doesn't mean they're not being freed? I don't know - there's the 
> problem, I'm not terribly clear on how to interpret the data.
> 
> Regarding the NSData I'm passed in my NSURLSessionDataTask completion block 
> (which are the biggest blocks I handle), I write that data to an open file 
> handle and that's the last time I reference it. I don't own that NSData 
> anyway, so even under classic MM I wouldn't do anything special about it. I 
> guess NSFileHandle could be retaining that NSData. I leave that file handle 
> open continually as long as a download stream is available, so it might be 
> that it's not releasing NSData blocks passed to -writeData: until it is 
> closed. That could explain what I'm seeing, though thinking about *why* 
> NSFileHandle would retain that data is not so obvious - why indeed? Wouldn't 
> it just copy that data to the file and release it?


___

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

Re: Debugging memory leak in NSURLSession with ARC

[Quincey Morris]

On Jan 1, 2015, at 17:20 , Graham Cox  wrote:
> 
> I'm using Allocations, but I'm finding the volume of data a bit overwhelming.
> 
> As an aside, Leaks shows nothing at all. Does that mean I'm not actually 
> leaking anything?

Forget Leaks, it’s an utter waste of time*. Use marked generations. The 
persistent increase in each generation is your real “leak”.

— In code where things happen repeatedly in the background, it can be hard to 
get your app into a quiescent state (in terms of allocations) so that you can 
find a good place to mark a new generation in Instruments. You may have 
temporarily add code to create and/or prolong such a quiescent state.

— It’s generally not useful to *start* by looking at the retain/release 
history. You’ll find problem objects easily, but you won’t know where they came 
from or why they didn’t get released.

— In the list of objects incrementally leaked in a generation**, look for the 
ones that you actually created (either objects of your own classes, or objects 
that were obviously created at a particular known place in your code). Out of 
those objects, try to eliminate the ones that appear to be “children” of 
others. 

— Ideally, you’ll find two sorta-kinda top-level objects remain. The 
presumption is then that there’s a reference cycle between them. For example, 
you might find that one is a window controller and the other is something in 
your data model***. Or, you might find that one is a block, and the other is 
whatever created the block.

— Audit the relevant source code. It’s often easiest and quickest to find the 
cycle just by inspecting the declarations/blocks.

— Only if that goes nowhere is it time to start analyzing the retain/release 
history of a generation in Instruments. By now, though, you should have a vague 
idea of what you’re looking for.

— Start by getting Instruments to pair as many retains and releases as it can 
automatically. 

— If that’s unproductive, start over and compare them all yourself. (But I 
should add that I haven’t spent much time doing this in Yosemite yet. The UI 
may be a bit different since Mavericks, and the auto-pairing may work a bit 
differently, too.)


** Create multiple generations, and look not only at what was leaked in each 
generation, but what’s repetitive in the pattern of leaks. Your real culprit 
should produce an identical pattern every time. Leaks unique to a generation 
aren’t what you’re looking for here. (I think this is the debugging equivalent 
of the second derivative.)

*** That usually means a window delegate reference needs to be manually nil’ed 
when the window closes, because we learned how to do bad memory management in 
the bad old days.

 That usually means the block and the ‘self’ it captured mutually refer to 
each other. I’m betting this is what’s wrong in your case.

* I should say, I’m not scorning Leaks. It’s just that experienced Obj-C 
developers tend not to make the kinds of mistakes that Leaks can detect. 
Experienced developers make other, better mistakes.

___

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

Re: Debugging memory leak in NSURLSession with ARC

[Graham Cox]

> On 2 Jan 2015, at 10:52 am, David Duncan  wrote:
> 
> The first thing to keep in mind is that unless otherwise qualified, all 
> object references are owned - locals, ivars, array entries, etc. The places 
> where this isn’t possible (such as structs) are flagged as compiler errors. 
> The lifetime of ownership can typically be considered as “usage scoped” - 
> that is, the object is owned up until its last reference, where by default 
> you can think of it as released. There are exceptions to both of these rules, 
> but they are generally minor and many likely line up with your expectations 
> as well.

Thanks David, that does agree with the way I've been thinking about memory 
management with ARC, so I guess I'm probably not too far wrong. I don't think 
I'm running into any of those corner cases - everything is an NSObject, no CF 
stuff (in my code), and no structs, etc.

> Generally the answer would be to stop referencing objects when you don’t need 
> them anymore, but Instruments’s Allocations tool would be the most useful 
> thing to use to debug this - in particular retain/release tracking would 
> likely be the most useful way to debug this issue. I would suspect the memory 
> blocks at hand are being allocated for receiving the downloaded data and 
> possibly wrapped as NSData objects.

I'm using Allocations, but I'm finding the volume of data a bit overwhelming.

As an aside, Leaks shows nothing at all. Does that mean I'm not actually 
leaking anything?

What I'm seeing sort of agrees with expectations - the memory usage graph has a 
broadly "sawtooth" waveform as each download task is created, builds up, is 
processed and released. However the underlying memory usage continues to climb, 
with the sawtooth on top. Breaking down the allocations shows that the 132KB 
bufers are the vast majority of the allocations, but maybe my interpretation 
that they're not being freed is wrong - they are listed but maybe that doesn't 
mean they're not being freed? I don't know - there's the problem, I'm not 
terribly clear on how to interpret the data.

Regarding the NSData I'm passed in my NSURLSessionDataTask completion block 
(which are the biggest blocks I handle), I write that data to an open file 
handle and that's the last time I reference it. I don't own that NSData anyway, 
so even under classic MM I wouldn't do anything special about it. I guess 
NSFileHandle could be retaining that NSData. I leave that file handle open 
continually as long as a download stream is available, so it might be that it's 
not releasing NSData blocks passed to -writeData: until it is closed. That 
could explain what I'm seeing, though thinking about *why* NSFileHandle would 
retain that data is not so obvious - why indeed? Wouldn't it just copy that 
data to the file and release it?

--Graham



___

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

Re: Debugging memory leak in NSURLSession with ARC

[David Duncan]

> On Jan 1, 2015, at 3:38 PM, Graham Cox  wrote:
> 
> Hi all,
> 
> I know I'm very, very late to the party, but I'm building my first ever 
> project with ARC instead of manual retain/release (which I was always very 
> comfortable with). Frankly, I'm finding it frustrating because it seems much 
> harder to know how memory is managed. Anyway. I will plough on - no doubt 
> I'll get used to it.

The first thing to keep in mind is that unless otherwise qualified, all object 
references are owned - locals, ivars, array entries, etc. The places where this 
isn’t possible (such as structs) are flagged as compiler errors. The lifetime 
of ownership can typically be considered as “usage scoped” - that is, the 
object is owned up until its last reference, where by default you can think of 
it as released. There are exceptions to both of these rules, but they are 
generally minor and many likely line up with your expectations as well.

The most prominent exception has to do with inner pointers to things that are 
not Obj-C objects (such as -[UIColor CGColor]) where ARC doesn’t take ownership 
of the returned object (because it isn’t an Obj-C object) and your last 
reference to the outer object (a UIColor in this case) ends before your usage 
of the inner non-object.

But thats just to help you understand/get used to ARC, it doesn’t likely apply 
to your issue at hand :).

> 
> I'm using NSURLSession and NSURLSessionDataTask to fetch chunks of data from 
> a .m3u8 playlist. It works pretty well, but I'm seeing a gradual increase in 
> memory usage as my app runs. Under classical memory management, I would 
> probably have little difficulty in isolating the problem, but with ARC I'm 
> finding it much harder to track down because it's unclear when certain 
> objects come to the end of their lives. Anyway, running in Instruments shows 
> a constant list of calls to malloc() from 
> HTTPNetStreamInfo::_readStreamClientCallBack(__CFReadStream*, unsigned long) 
> in the CFNetwork library, allocating 132KB. These blocks are allocated at a 
> high rate (over 100x per second) as the app runs, and as far as I can see are 
> never freed. I'm not directly using this API, it must be something internal 
> to NSURLSession.
> 
> How can I ensure that these blocks are freed? I'm assuming that a leak in the 
> OS of this sort would have been spotted, so my assumption here is that I'm 
> doing something wrong that prevents proper freeing.

Generally the answer would be to stop referencing objects when you don’t need 
them anymore, but Instruments’s Allocations tool would be the most useful thing 
to use to debug this - in particular retain/release tracking would likely be 
the most useful way to debug this issue. I would suspect the memory blocks at 
hand are being allocated for receiving the downloaded data and possibly wrapped 
as NSData objects.

> 
> The way I'm using NSURLSession seems to be "normal", as far as I can tell. I 
> have an object that allocates a NSURLSession and this session exists for as 
> long as the task runs, which can be a very long time. Each "chunk" of data is 
> added to the session as a NSURLSessionDataTask and I supply a completion 
> block. The completion block simply appends the data it receives to a file and 
> fires off some notifications. The completion block may or may not schedule 
> the download of the following chunk, depending on various factors, but it 
> doesn't do anything special to tell the task it has finished - as far as I 
> can tell from documentation, the fact the completion block is called is 
> because the task has finished, so I can just forget about it.
> 
> The session itself is invalidated when the owning object is dealloced, but 
> that might be hours or days later when the user decides to discard the task. 
> Otherwise it stays alive indefinitely. I'm wondering if that's the right 
> thing to do? The docs suggest that a NSURLSession is somewhat like a tab in a 
> web browser, so it lives as long as that tab exists.
> 
> Any clues as to how I can track down the leak or whether there's an obvious 
> missing step that should free temporary buffers used by NSURLSessionDataTask 
> would be gratefully received at this point.
> 
> 
> --Graham
> 
> 
> 
> ___
> 
> 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/david.duncan%40apple.com
> 
> This email sent to david.dun...@apple.com

--
David Duncan


___

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/o

Debugging memory leak in NSURLSession with ARC

[Graham Cox]

Hi all,

I know I'm very, very late to the party, but I'm building my first ever project 
with ARC instead of manual retain/release (which I was always very comfortable 
with). Frankly, I'm finding it frustrating because it seems much harder to know 
how memory is managed. Anyway. I will plough on - no doubt I'll get used to it.

I'm using NSURLSession and NSURLSessionDataTask to fetch chunks of data from a 
.m3u8 playlist. It works pretty well, but I'm seeing a gradual increase in 
memory usage as my app runs. Under classical memory management, I would 
probably have little difficulty in isolating the problem, but with ARC I'm 
finding it much harder to track down because it's unclear when certain objects 
come to the end of their lives. Anyway, running in Instruments shows a constant 
list of calls to malloc() from 
HTTPNetStreamInfo::_readStreamClientCallBack(__CFReadStream*, unsigned long) in 
the CFNetwork library, allocating 132KB. These blocks are allocated at a high 
rate (over 100x per second) as the app runs, and as far as I can see are never 
freed. I'm not directly using this API, it must be something internal to 
NSURLSession.

How can I ensure that these blocks are freed? I'm assuming that a leak in the 
OS of this sort would have been spotted, so my assumption here is that I'm 
doing something wrong that prevents proper freeing.

The way I'm using NSURLSession seems to be "normal", as far as I can tell. I 
have an object that allocates a NSURLSession and this session exists for as 
long as the task runs, which can be a very long time. Each "chunk" of data is 
added to the session as a NSURLSessionDataTask and I supply a completion block. 
The completion block simply appends the data it receives to a file and fires 
off some notifications. The completion block may or may not schedule the 
download of the following chunk, depending on various factors, but it doesn't 
do anything special to tell the task it has finished - as far as I can tell 
from documentation, the fact the completion block is called is because the task 
has finished, so I can just forget about it.

The session itself is invalidated when the owning object is dealloced, but that 
might be hours or days later when the user decides to discard the task. 
Otherwise it stays alive indefinitely. I'm wondering if that's the right thing 
to do? The docs suggest that a NSURLSession is somewhat like a tab in a web 
browser, so it lives as long as that tab exists.

Any clues as to how I can track down the leak or whether there's an obvious 
missing step that should free temporary buffers used by NSURLSessionDataTask 
would be gratefully received at this point.


--Graham



___

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

Re: Bifurcating text color in QL on X.6, how?

[Quincey Morris]

On Jan 1, 2015, at 13:25 , Eden Smallwood  wrote:
> 
>   How does Apple know to make the text white in one place and black in 
> the other?

How are you choosing the color for your text? Have you tried [NSColor 
textColor] or perhaps [NSColor controlTextColor]?
___

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

Re: Bifurcating text color in QL on X.6, how?

[Jens Alfke]

> On Jan 1, 2015, at 1:25 PM, Eden Smallwood  wrote:
> 
>   If you’re thinking "Wh on Bk and Bk on Wh, therefore XOR to the 
> rescue", I’ve tried every conceivable setting of cgBlendMode and 
> nsCompositingMode and nothing has any effect whatsoever on the text color 
> which results in the window.

XOR-based drawing modes are pretty much useless in anything other than 1-bit 
(b/w) graphics. I don't think CG even supports them.

>   Or perhaps it’s possible to detect the “background color” of the 
> current CGContext or NSContext?  But this notion doesn’t seem to exist. 

I don't think so. The individual calls don't draw both foreground and 
background, so the background is simply the color of the pixels that already 
exist in the buffer at the time you're drawing. Or of the pixels your pixmap 
will be composited onto when it's drawn, if it's transparent.

I don't know much about QuickLook generators, but it looks like there are a lot 
of possible data types that the generator can return the preview as, including 
textual ones like RTF. If so, it's possible the preview you saw is textual and 
the Finder is overriding its text styling to force a contrasting color.

—Jens
___

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

Bifurcating text color in QL on X.6, how?

[Eden Smallwood]

Greetings, O readers of the sacred list !

Merry Xmas, and a Happy New Macintosh, btw.


On X.6 Snow Leopard, a QuickLook preview executed from the Finder is 
displayed in a window with a translucent black background.  The text color is 
white, ergo.

On the same system, same file, same QL generator, the preview shown in 
the Finder’s ‘Info’ window is drawn on an opaque white background, the text is 
black.

How does Apple know to make the text white in one place and black in 
the other?

If you’re thinking "Wh on Bk and Bk on Wh, therefore XOR to the 
rescue", I’ve tried every conceivable setting of cgBlendMode and 
nsCompositingMode and nothing has any effect whatsoever on the text color which 
results in the window.

Or perhaps it’s possible to detect the “background color” of the 
current CGContext or NSContext?  But this notion doesn’t seem to exist.  The 
context’s APIs are 99% set(), and basically no get().  And if the background 
color is an aspect of the containing window, well, fine, but a QL plugin has no 
pointer to its containing window.  Argh.

As it stands now, my text is invisible in one place or the other place.

Please shock me with what a simple thing I’m missing somewhere, thanks.
___

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

Re: Image Sizing

[Charles Jenkins]

Thank you all for that good information. :-)  

I once had AirDisplay for my iPad, so I need to re-download it and see what I 
need to do to get it going with Yosemite.

—

Charles Jenkins

___

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

Re: Application Crashing Under Mavericks, but not Yosemite (Entitlements Issue?)

[Uli Kusterer]

On 01 Jan 2015, at 16:15, SevenBits  wrote:
> Uli: is it possible to create a category which defines a method called 
> containsString:, and only have it activate on 10.9 or lower and use the new 
> Apple method on 10.10 and above?

 In theory, you could add code on 10.8 and earlier that registers the IMP of 
sb_containsString: for the selector containsString: as well, using the ObjC 
runtime API, or put the category in a loadable bundle and not load that on 
10.10 and later, but I don’t recommend it as a general approach.

 It’s just too easy to run into conflicts with someone else’s category. Also, 
sometimes Apple privately implement a selector with different parameter types 
in an older OS version, then change its parameters but not the name before they 
make it public, and you’d end up failing to replace it (or worse, replacing it 
successfully and breaking the OS on the way).

 But yeah, unless you set the min *and* max OS version to <= 10.9, you prolly 
won’t get an error message when you use this selector.

Cheers,
-- Uli Kusterer
“The Witnesses of TeachText are everywhere...”
http://zathras.de


___

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

Fwd: Application Crashing Under Mavericks, but not Yosemite (Entitlements Issue?)

[SevenBits]

-- Forwarded message --
From: *SevenBits* 
Date: Thursday, January 1, 2015
Subject: Application Crashing Under Mavericks, but not Yosemite
(Entitlements Issue?)
To: Uli Kusterer 


On Thursday, January 1, 2015, Uli Kusterer > wrote:

> On 01 Jan 2015, at 02:50, Jack Brindle  wrote:
> > You might want to extend that. The header file indicates that
> containsString: _only_ is available in OS X starting with 10.10 and iOS
> starting with 8.0. I would expect this to crash, or at least behave very
> poorly, under any prior OS since the call simply doesn’t exist there.
> >
> > Interesting that the only place it appears to be documented by Apple is
> in the header file. It is widely “documented” at various web sites, but
> using any call based on that is definitely rolling the dice. The central
> rule is that if you are releasing code for others to run, be sure to use
> calls that Apple documents to be available for the earliest targeted OS.
> >
> > I’d replace it with a more suitable call, which appears to be
> rangeOfString:options: The header file indicates it should be called with
> no options. in fact you probably should read the NSString header file info
> for that call. It is somewhat interesting.
>
>  A good workaround is probably to create your own equivalent call with an
> identical signature in a category and just replace all calls to
> containsString with that:
>
> @implementation NSString (SBContainsStringBackwardsCompat)
>
> -(BOOL) sb_containsString: (NSString*)inString
> {
> return [self rangeOfString: inString options: 0].location !=
> NSNotFound;
> }
>
> @end
>
> (Warning: code written in mail, never compiled) Then, when your baseline
> rises to 10.10, you can just do a search-and-replace of sb_containsString:
> to containsString:.


I never even realized that you guys had resumed this thread. Sorry for not
piping in.

Yeah, that ultimately was my problem. I have a category like what you
describe, because I had begun writing my code on 10.9, but I had forgotten
to use it when coding with the 10.10 SDK when I upgraded to Yosemite.
Because the call is present on that OS version, there was no crash there
and so I did not suspect that there were issues. I've refactored the code
to change all calls over to my category, which solved this problem.

The futile aspect of all this is that containsString: is never mentioned in
the NSString documentation, so I never knew that it had been added in
Yosemite. (Why can't all of the new stuff be in the documentation? It seems
like quite a few properties and calls are missing...)

This is quite frustrating at times. Oh, well. Thanks for contributing, you
guys.

Uli: is it possible to create a category which defines a method called
containsString:, and only have it activate on 10.9 or lower and use the new
Apple method on 10.10 and above?


>
> Cheers,
> -- Uli Kusterer
> “The Witnesses of TeachText are everywhere...”
> http://zathras.de
>
>
___

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

Re: Application Crashing Under Mavericks, but not Yosemite (Entitlements Issue?)

[Roland King]

> On 1 Jan 2015, at 23:00, Uli Kusterer  wrote:
> 
> On 01 Jan 2015, at 02:50, Jack Brindle  wrote:
>> You might want to extend that. The header file indicates that 
>> containsString: _only_ is available in OS X starting with 10.10 and iOS 
>> starting with 8.0. I would expect this to crash, or at least behave very 
>> poorly, under any prior OS since the call simply doesn’t exist there.
>> 
>> Interesting that the only place it appears to be documented by Apple is in 
>> the header file. It is widely “documented” at various web sites, but using 
>> any call based on that is definitely rolling the dice. The central rule is 
>> that if you are releasing code for others to run, be sure to use calls that 
>> Apple documents to be available for the earliest targeted OS.
>> 
>> I’d replace it with a more suitable call, which appears to be 
>> rangeOfString:options: The header file indicates it should be called with no 
>> options. in fact you probably should read the NSString header file info for 
>> that call. It is somewhat interesting.
> 
> A good workaround is probably to create your own equivalent call with an 
> identical signature in a category and just replace all calls to 
> containsString with that:
> 
> @implementation NSString (SBContainsStringBackwardsCompat)
> 
> -(BOOL) sb_containsString: (NSString*)inString
> {
>   return [self rangeOfString: inString options: 0].location != NSNotFound;
> }
> 
> @end
> 

I suspect this thread died at the point the OP realised they used a 10.10 
method in the latest changes to the code which broke pre-10.10 compatibility, 
it had nothing to do with entitlements at all and backed that change out and 
replaced it with something pre 10.10 compatible. Would have been nice to have 
seen a follow up so the thread can help other people searching. 

SevenBits, people pitched in to help you here, what was the final resolution or 
do you still have an issue? 


___

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

Re: Image Sizing

[Gleb Dolgich]

Duet adds a connected iPad as a second display which you can set to use Retina 
resolution. I just tried it and it seems to work pretty well with only a slight 
lag. I bought Duet with the main purpose of testing my apps at the Retina 
resolution without having to switch the main display to one.

http://www.duetdisplay.com

-- 
Gleb


> On 1 Jan 2015, at 14:55, Uli Kusterer  wrote:
> 
> You might also be able to run AirDisplay or something equivalent on your iPad 
> to add a (slow) second Retina display to your Mac, it’s been ages since I 
> even considered that option.


___

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

Re: Application Crashing Under Mavericks, but not Yosemite (Entitlements Issue?)

[Uli Kusterer]

On 01 Jan 2015, at 02:50, Jack Brindle  wrote:
> You might want to extend that. The header file indicates that containsString: 
> _only_ is available in OS X starting with 10.10 and iOS starting with 8.0. I 
> would expect this to crash, or at least behave very poorly, under any prior 
> OS since the call simply doesn’t exist there.
> 
> Interesting that the only place it appears to be documented by Apple is in 
> the header file. It is widely “documented” at various web sites, but using 
> any call based on that is definitely rolling the dice. The central rule is 
> that if you are releasing code for others to run, be sure to use calls that 
> Apple documents to be available for the earliest targeted OS.
> 
> I’d replace it with a more suitable call, which appears to be 
> rangeOfString:options: The header file indicates it should be called with no 
> options. in fact you probably should read the NSString header file info for 
> that call. It is somewhat interesting.

 A good workaround is probably to create your own equivalent call with an 
identical signature in a category and just replace all calls to containsString 
with that:

@implementation NSString (SBContainsStringBackwardsCompat)

-(BOOL) sb_containsString: (NSString*)inString
{
return [self rangeOfString: inString options: 0].location != NSNotFound;
}

@end

(Warning: code written in mail, never compiled) Then, when your baseline rises 
to 10.10, you can just do a search-and-replace of sb_containsString: to 
containsString:.

Cheers,
-- Uli Kusterer
“The Witnesses of TeachText are everywhere...”
http://zathras.de


___

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

Re: Image Sizing

[Uli Kusterer]

On 31 Dec 2014, at 14:04, Charles Jenkins  wrote:
> I have a non-retina Mac and no experience knowing what happens to graphics 
> when used on a retina screen. I bought PixelCut's PaintCode as a Christmas 
> present to myself so that my images could be made resolution-independent, but 
> I'm having quite a bit more difficulty getting good results than I imagined, 
> partly because of Cocoa issues.  

 You’re aware that you can usually try out Retina on a non-Retina Mac, right? 
As long as you have a sufficiently large screen, you can use Quartz Debug.app 
to turn on Retina sizes for your screen, then choose a Retina resolution in the 
Displays System Preference (Resolution: Scaled, then you get a list of 
resolutions).

 It’s a bit annoying because if you switch a 2560x1440 screen to 2x, you get 
all applications thinking they’re 1280x720, which is just a tad too small to 
pass for a MacBook Air 11” (1366x768), so some stuff is cut off, but all 
rendering in your app will be Retina, so you can see what happens, if at a 
magnified size.

 You might also be able to run AirDisplay or something equivalent on your iPad 
to add a (slow) second Retina display to your Mac, it’s been ages since I even 
considered that option.

> First, am I right that there is no way to ask an NSToolbar or NSToolbarImage 
> what size its graphic should be? In searching the documentation, I found it 
> seems to say toolbar images come in two sizes, 32x32 or 24x24, and if they 
> need to be different, the toolbar will pick the closest provided one and 
> scale it. I hate hard-coding sizes like this, but am I right there's no other 
> option?

 All images on Retina essentially work like icons. You provide 1x (32x32px and 
24x24px) variants of your images, and also add 2x variants (which would be 
64x64px and 48x48px, so still 32x32pt and 24x24pt). You can just add 
multi-representation TIFFs that contain all the sizes, and NSImage will pick 
the best one for where it’s drawn. PaintCode should be able to generate such 
multi-resolution TIFFs for you (Opacity certainly does, and has presets for the 
various icon types that export all required sizes).

> Second, what about images in a Source View? Mine appear at 17x17 in the NIB. 
> Are they always that size, even on a retina screen, or do I need to learn how 
> to deal with the possibility of a changing size? I haven't yet been able to 
> find any documentation on this at all, but that may only mean I used the 
> wrong search keywords.

 You can probably assume the *point* size will stay this way, but you still 
need to provide 2x representations.

Cheers,
-- Uli Kusterer
“The Witnesses of TeachText are everywhere...”
http://zathras.de


___

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