Ok Jens, my method turned so complicated due to hundreds of relationships, undo, fileWrappers, copy/paste, new object IDs... That I'm going to do as you say.
I am going to load the image and leave it within the NSView object. When I delete an NSView containing the image, I put its pointer within the undo stack, then I release the NSView (which doesn't get deallocated therefore). Thin way when invoking the undo, I get back all the relashionships that object had with other objects. When saving, I write the image's NSData within the filePackage. When re-loading a file, I read that NSData and create the image. It sounds linear and clean. Good luck to myself. I'll let you know. Regards -- Leonardo > Da: Jens Alfke <j...@mooseyard.com> > Data: Sat, 8 Feb 2014 16:37:01 -0800 > A: Leonardo <mac.iphone....@gmail.com> > Cc: <cocoa-dev@lists.apple.com> > Oggetto: Re: Managing image loading > > > On Feb 8, 2014, at 3:58 AM, Leonardo <mac.iphone....@gmail.com> wrote: > >> When the user imports a new image, I quickly copy the image to a temporary >> folder, then I add this latest file reference to the document¹s >> NSFileWrapper. >> I just create the file¹s fileWrapper using its URL, so I do not read its >> content and create the fileWrapper by the NSData. > > This seems like a hacky workaround for the kind of temporary storage that > you'd already get from virtual memory. See below. > >> Why don¹t I add the file¹s NSData to the fileWrapper but I add just its URL >> reference? Because I don¹t really know whether the fileWrapper uses the disk >> or keeps the NSData in memory. So in case of a 1GB file I do not engulf the >> app. > > It's a 64-bit app, presumably, so you have no worries about running out of > address space. If physical RAM is running low, then the OS will just write > part of your address space to disk to make room; when you access that address > space again, it'll read it back in. > > Basically the virtual memory system is going to do what your > temporary-file-copying solution would have done, only it's doing it more > efficiently because (a) it only writes it to disk if there's not enough RAM; > (b) it only copies as much of the data as needed; and (c) it'll free up that > disk space automatically later on. > > I think I asked this before, but: Do you already have a running app that is > having performance problems working with large or lots of images? Or are you > simply imagining that your app might run into these problems, without knowing > whether that's true? In the latter case, _especially_ if you're a novice > developer or new to the platform, please put off worrying about performance > until later. > > 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
