Re: NSImage / large image performance hit / memory paging bug ?
Re: NSImage / large image performance hit / memory paging bug ?
- Subject: Re: NSImage / large image performance hit / memory paging bug ?
- From: "John C. Randolph" <email@hidden>
- Date: Mon, 16 Jul 2001 14:52:10 -0700
Bob,
You're getting messed up by a combination of Mach's default paging
behaviour, and the fact that NSImage is not intended for image data
bigger than your physical RAM.
The problem is this:
NSBitmapImageRep will malloc() off a single block to store its pixel
data. When you page-fault on any page in that block, the VM system will
attempt to bring in all of the pages in that block, not just the one
that triggered the fault. *Usually*, this is a good thing. However, in
your situation, by the time the last page is read in, the first page had
to be dropped to make room! (This was the case under NeXTSTEP, and is
probably still the case under Mac OS X)
The solution that we came up with back at Chromagrafx (which we learned
from somebody at TRW), is to segment the image, and use a tile object
for each segment of the image (tiles being sized to fit closely into one
vm_page_size), and go ahead and have many, many entries in the malloc
table. It doesn't hurt to have as many malloc table entries as you want.
You'll need to write your own subclass of NSImageRep which owns a set of
tiles, each of which owns an array of pixels.
BTW, you should talk to the guys at Caffeine Software (makers of
TIFFAny), and see if you can save yourself a lot of time and trouble by
making your app a front-end to the TIFFany engine.
Good luck,
-jcr
[Objc retain];