On Thu, Jan 15, 2009 at 12:16 AM, Michael B Johnson <w...@pixar.com> wrote: > > On Jan 14, 2009, at 9:13 PM, Joe Ranieri wrote: > >>> NSDictionary* dict = [NSDictionary >>> dictionaryWithObjectsAndKeys:font, NSFontAttributeName, self.textColor, >>> NSForegroundColorAttributeName, nil]; >>> NSAttributedString* aStr = [[[NSAttributedString alloc] >>> initWithString:str attributes:dict] autorelease]; >>> >>> NSImage* image = [[NSImage alloc] initWithSize:imgSize]; >> >> You're leaking this NSImage. > > sigh. I knew I should have explained this more. > > I know, in the code snippet I sent, that the NSImage is being leaked. But > it's tickling the bug (where in the app, I have 100s of NSImages, and I need > to keep them around). Why, on a machine with 32GB of RAM, and 1.5GB of > VRAM, would having 350 1920x1080 NSImages live in the app be a problem? > Make my app page, sure, but kill the window server so bad that it needs to > get restarted? > > Not acceptable.
350 32-bit images of that size works out to 2.7GB of memory. That's getting dangerously close to the limit of a 32-bit process. That limit is nominally 4GB, but system libraries decrease it significantly, and of course the window server has other stuff to keep track of than your images. NSImages created in this way use invisible windows which live in the window server, so the memory usage counts against it, not your app. When the window server runs out of address space and allocations begin to fail, it probably can't recover nicely and down you go. Now, should this happen? No. But UNIX is notoriously bad about recovering from low-resource situations. The standard answer to just about any resource allocation failure is to crash. Ideally the window server should not be killed by one runaway process, but such is not the world we live in. As to the solution, draw into something you *know* lives in your process and not on the window server, like an NSBitmapImageRep wrapped in an NSGraphicsContext. Then you'll still kill your program (unless you're building a 64-bit app), but you won't kill the system. Mike _______________________________________________ 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
