Re: Managing image loading
Re: Managing image loading
- Subject: Re: Managing image loading
- From: Jens Alfke <email@hidden>
- Date: Tue, 04 Feb 2014 07:41:41 -0800
On Feb 4, 2014, at 3:05 AM, Leonardo <email@hidden> wrote:
> My app displays several images on several pages.
> Since the app displays one page per time, I would like to optimize the
> memory management at loading and displaying the images.
It'd be best to explicitly release/free the images for a page when that page stops being displayed.
> to reference all the images when opening a document. So, I thought, the
> images get really loaded and displayed at the time I select a given page,
> and discarded (in the cache) when I change page. Does it really work that
> way?
I don't know. NSImage is a very high-level API that does a lot of caching behind the scenes, and the AppKit team tends to make subtle changes to its behavior from one release to another. I don't remember seeing anything in the docs that states that an image's pixmap can be purged to make room. (And the image itself doesn't know when the app changes pages, so changing pages won't itself trigger any cleanup.)
If you're concerned about memory usage, NSImage is not the best API to use. You can get more control by using NSImageRepresentation directly, and even more by using CGImage.
On the other hand, how large are these images? (Do the math: byte usage = pixel height x pixel width x 4.) How many pages do you expect documents to have? Is memory really a concern when people's computers have gigabytes of RAM and (often) very fast SSDs? Remember, "Premature optimization is the root of all evil."
> Second question. In case the user imports a new image, I presume I should
> immediately copy the image file within the filePackage then call
> initByReferencingFile.
No, you wait until told to save changes to the document. Consider what happens if the user decides to close without saving, or revert, or to Save As to a different file.
I'm not sure of the answer to your file-wrapper question; that's not an API I've used much.
—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