On 10/03/2013, at 7:12 PM, Markus Spoettl <ms_li...@shiftoption.com> wrote:
> Why does it conform to NSCoding if it's not safe to use? I'm not sure I said it wasn't safe, just that it wasn't a good idea. An NSImage can contain multiple representations of the same image, often in highly expanded forms, e.g. the actual bitmaps. A 10MB JPEG can easily end up as a 250MB NSImage - you don't want that in your archive. If you can archive the original compressed data, that's ideal. If not, using the TIFFRepresentation is at least a better option, unless there's a PDF representation that you could use instead (which you have to go and look for yourself), which could well be considerably smaller than the TIFF . I recently ran into the fact that if you create an NSColor with a pattern image, archiving the colour archives the NSImage. A trivial 512 x 512 pixel image became a 41MB NSImage, archived individually for every instance of that colour, which ran me out of memory in the 32-bit build of our app during a document save (Greatly exacerbated by the fact that NSFileWrapper copies a chunk of immutable data given to it instead of retaining it - there just isn't room for two enormous blocks in memory at once). Other parts of our app go to great lengths to a) archive the original data wherever possible and b) eliminate duplicates of that image data by using a hash of the data to identify duplicates. The pattern case passed us by, though now I'm aware of it I can fit it into the rest of the app's imaging scheme. Back to your case, since archiving NSImages can hit memory limits easily, perhaps there's a memory issue somewhere where you (or the OS) aren't checking that an allocation succeeded? Fixing this up in an existing archive isn't difficult - decide how your archives are going to save images from now on and use a new archive key. Then when importing you can check which key it has and either import the old NSImage archive, or do something a lot smarter with the new format image data. Also adding checks at dearchiving time for bad image size will catch the case you have a problem with - it will be better to ignore the errant image (and perhaps notify the user) than crashing. --Graham _______________________________________________ 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
