3

我有一个 IKImageView，我将 CGImages（我用 NSImages 制作）放到它上面。然而，一个正常的 200DPI 8.5/11 页面需要大约 3 秒才能出现，一次出现在一边大约 2 英寸（屏幕）的矩形中。这真的很烦人。有没有解决的办法？

或者，有没有办法双重缓冲视图？有 2 个 IKImageViews 并绘制成一个，然后显示它？

ETA：将我的滚动视图（里面有 ikimageviews）加倍，然后绘制它们，然后取消隐藏它们，似乎没有帮助......或者，也许它有一点帮助，但没有多大帮助

我用仪器做了一点探索，发现 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

我不确定那告诉我什么...

编辑：为了记录，问题不是数据大小。我有一个旧版本的程序，它使用不推荐使用的 quickdraw 方法调用。当我将图像放大到 300% 时，一个屏幕像素 = 一个图像像素，所以它需要使用整个图像，它仍然一页接一页地压缩。

我被最初写这篇文章的人嘲笑了，因为他的版本在他古老的 10.3 G5 上比在我最新的 Intel 盒子上运行得更快。至少快 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 回答