Re: Managing image loading
Re: Managing image loading
- Subject: Re: Managing image loading
- From: Leonardo <email@hidden>
- Date: Tue, 11 Feb 2014 16:13:09 +0100
- Thread-topic: Managing image loading
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 <email@hidden>
> Data: Sat, 8 Feb 2014 16:37:01 -0800
> A: Leonardo <email@hidden>
> Cc: <email@hidden>
> Oggetto: Re: Managing image loading
>
>
> On Feb 8, 2014, at 3:58 AM, Leonardo <email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden