IKImageView choppy?

Question

I have an IKImageView, and I'm putting CGImages (That I make out of NSImages) onto it. However, a normal 200DPI 8.5/11 page takes like 3 seconds to come up, appearing in rectangles about 2inches (screen) on a side at a time. This is really annoying. Is there a way around this?

Alternatively, is there a way to double buffer the view? To have 2 IKImageViews and draw into one, and then display it?

ETA: doubling my scrollviews (with ikimageviews inside) and then drawing into them, and then unhiding them, doesn't seem to help... or, maybe it helps a little, but not much

I did a little poking around with instruments, and found that a lot of work seems to be being done in memcopy:

  22 commpage [libSystem.B.dylib] 78.0  __memcpy
  21 ImageIO 37.0  CGImageReadGetBytesAtOffset
  20 ImageIO 37.0  CGImageReadSessionGetBytes
  19 ImageIO 37.0  myTIFFReadProc
  18 libTIFF.dylib 37.0  TIFFReadRawStrip1
  17 libTIFF.dylib 37.0  TIFFFillStrip
  16 libTIFF.dylib 37.0  _cg_TIFFReadEncodedStrip
  15 ImageIO 37.0  copyImageBlockSetTIFF
  14 ImageIO 37.0  ImageProviderCopyImageBlockSetCallback
  13 CoreGraphics 37.0  CGImageProviderCopyImageBlockSet
  12 CoreGraphics 37.0  img_blocks_create
  11 CoreGraphics 37.0  img_blocks_extent
  10 CoreGraphics 37.0  img_interpolate_extent
   9 CoreGraphics 37.0  img_data_lock
   8 CoreGraphics 37.0  CGSImageDataLock
   7 libRIP.A.dylib 37.0  ripc_AcquireImage
   6 libRIP.A.dylib 37.0  ripc_DrawImage
   5 CoreGraphics 37.0  CGContextDrawImage
   4 ImageKit 37.0  -[IKImageLayer drawInContext:]
   3 QuartzCore 37.0  tiled_layer_render(_CAImageProvider*, unsigned int, unsigned int, unsigned int, unsigned int, void*)
   2 QuartzCore 37.0  CAImageProviderThread(void*)
   1 libSystem.B.dylib 37.0  _pthread_wqthread
   0 libSystem.B.dylib 37.0  start_wqthread

I'm not sure what that tells me though...

EDIT: For the record, the problem is NOT data size. I have an old version of the program, that uses deprecated quickdraw method calls. When I zoom the image up to 300%, so that one screen pixel = one image pixel, so it needs to be using the whole image, it STILL zips right along page after page.

I'm being ridiculed by the guy who wrote this originally, because his version moves faster on his ancient 10.3 G5 than it does on my up-to-date Intel box. faster by at least a factor of 10.

Answer 1

200DPI 8.5/11 page

Assuming those are in RGB color, that's 11.22 megabytes of pixels per image. Your application uses a lot of memory, and drawing 3.74 megapixels (regardless of color space) is going to be slow.

2 inches (screen) on a side

Make use of that. Figure out how many screen pixels 2 inches is, using the 72 dpi constant and the window's user-space scale factor, and rasterize your pages to that size. Currently, those rectangles will be 144 points on a side, and a 144×144 image is very efficient to have in memory and to draw.

If you have a zoom setting, you'll want to invalidate your cache of these images when it changes, and re-compute each image no earlier than when your view gets told to draw.