FROM : Ricky Sharp
DATE : Fri Jan 11 22:34:23 2008
On Jan 11, 2008, at 2:10 PM, glenn andreas wrote:
> NSImage's +imageNamed: is documented as searching the named images
> cache, the apps main bundle, and then the AppKit framework bundle.
> Unfortunately, I've got code in a private framework that wants to
> get the image stored that framework (which isn't thus searched).
>
> Is there some way to add a framework to this search path? (Which
> would be best, because it will allow any object, such as a button,
> that has an image name to automatically work correctly) Or at least
> a way to explicitly pass a bundle to search (via a hypothetical
> +imageNamed:fromBundle:). The fall back, of course, is to get all
> the possible file extensions from NSImage and manually try each and
> every one of them, but I'd rather not have to duplicate this logic
> (plus this fails to support the generic button using a named image
> that resides in the private framework)...
As others have pointed out, use NSBundle's pathForImageResource. I
created an image factory that knows how to scan multiple areas looking
for images.
> I suppose I could also, at startup, go through all the images in the
> framework, load them, and then do a "setName:" to get them in the
> cache (but this seems like it could impact program launch times)
Well, that may not be bad since load times are often very, very low.
It's probably the case where image data is not decoded until you're
actually drawing things.
For example, all my images are PDF (to support res-ind). While my
factory loads them on-demand (and not all at once), I did measure the
total loading time over the lifetime of the app. This was the time
taken to actually alloc/init NSImage images and then call setName:.
When the images were then _drawn_, that's where the bulk of the time
was taken. Maybe this is specific to PDF; I don't know. For PDF the
raw data is loaded, but not "decoded" until drawn; also at the time of
drawing, that's where you end up with cached reps (e.g. a cached
bitmapimagerep) that will ultimately speed up drawing for the 2nd,
etc. times the image is drawn.
___________________________________________________________
Ricky A. Sharp mailto:<email_removed>
Instant Interactive(tm) http://www.instantinteractive.com
DATE : Fri Jan 11 22:34:23 2008
On Jan 11, 2008, at 2:10 PM, glenn andreas wrote:
> NSImage's +imageNamed: is documented as searching the named images
> cache, the apps main bundle, and then the AppKit framework bundle.
> Unfortunately, I've got code in a private framework that wants to
> get the image stored that framework (which isn't thus searched).
>
> Is there some way to add a framework to this search path? (Which
> would be best, because it will allow any object, such as a button,
> that has an image name to automatically work correctly) Or at least
> a way to explicitly pass a bundle to search (via a hypothetical
> +imageNamed:fromBundle:). The fall back, of course, is to get all
> the possible file extensions from NSImage and manually try each and
> every one of them, but I'd rather not have to duplicate this logic
> (plus this fails to support the generic button using a named image
> that resides in the private framework)...
As others have pointed out, use NSBundle's pathForImageResource. I
created an image factory that knows how to scan multiple areas looking
for images.
> I suppose I could also, at startup, go through all the images in the
> framework, load them, and then do a "setName:" to get them in the
> cache (but this seems like it could impact program launch times)
Well, that may not be bad since load times are often very, very low.
It's probably the case where image data is not decoded until you're
actually drawing things.
For example, all my images are PDF (to support res-ind). While my
factory loads them on-demand (and not all at once), I did measure the
total loading time over the lifetime of the app. This was the time
taken to actually alloc/init NSImage images and then call setName:.
When the images were then _drawn_, that's where the bulk of the time
was taken. Maybe this is specific to PDF; I don't know. For PDF the
raw data is loaded, but not "decoded" until drawn; also at the time of
drawing, that's where you end up with cached reps (e.g. a cached
bitmapimagerep) that will ultimately speed up drawing for the 2nd,
etc. times the image is drawn.
___________________________________________________________
Ricky A. Sharp mailto:<email_removed>
Instant Interactive(tm) http://www.instantinteractive.com
| Related mails | Author | Date |
|---|---|---|
| glenn andreas | Jan 11, 21:10 | |
| David Spooner | Jan 11, 22:08 | |
| Ricky Sharp | Jan 11, 22:34 | |
| glenn andreas | Jan 11, 23:12 |






Cocoa mail archive

