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: Robert Miller <email@hidden>
- Date: Mon, 16 Jul 2001 18:33:32 -0400
- Organization: RFM & Associates
John,
Thanks for the keen insight.
"John C. Randolph" wrote:
>
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];