3

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.

4

1 に答える 1

2

200DPI 8.5/11 ページ

それらが RGB カラーであると仮定すると、画像あたり 11.22 メガバイトのピクセルになります。アプリケーションが大量のメモリを使用し、(色空間に関係なく) 3.74 メガピクセルの描画が遅くなります。

片側2インチ（画面）

それを利用してください。定数 72 dpi とウィンドウのユーザー空間倍率を使用して、2 インチの画面ピクセル数を計算し、ページをそのサイズにラスタライズします。現在、これらの長方形は一辺が 144 ポイントになり、144×144 の画像はメモリに保持して描画するのに非常に効率的です。

ズーム設定がある場合は、変更時にこれらの画像のキャッシュを無効にし、ビューが描画するように指示される前に各画像を再計算する必要があります。

于 2010-07-30T23:27:14.300 に答える