2010-08-09 10 views
8

Aquí está el código:¿Por qué este código CATiledLayer/PDF es lento?

https://www.dropbox.com/s/o42wy36x4qhrbpt/PDFScroller.zip

tomé el 2010 Código PhotoScroller muestra de la WWDC que implementa anidada UIScrollViews para el zoom, dentro de un UIScrollView para paginación y cambiarse por lo que pensé que sería mínima cantidad de código necesario para mostrar un PDF de varias páginas en lugar de imágenes.

Funciona. Pero es lento en mi iPhone4, unos tres segundos para pintar la primera página, e incluso más lento en mi iPod Touch. Puedo verlo pintando las fichas individuales. Este mismo PDF ya se abre más rápidamente, sin un dibujo de mosaico visible, en una implementación alternativa CATiledLayer que tengo que simplemente usa un solo CATiledLayer/UIScrollView y toca eventos para cambiar páginas. Me gustaría utilizar esta técnica PhotoScroller, es muy agradable.

Lo vi con la muestra de la CPU en instrumentos, y no parece ser el código de procesamiento de PDF, parece que el tiempo se tarda en enhebrar y enviar mensajes. Agradecería que alguien pudiera ayudar a señalar qué está haciendo esta muestra para incurrir en gastos generales.

Gracias,

Jim


Actualización 1: Había utilizado originalmente la técnica TilingView clase desde el código de ejemplo de definir

+ (Class) layerClass { 
    return [CATiledLayer class]; 
} 

Y luego el dibujo en - (void)drawRect:(CGRect)rect pero cambió a la subclase CATiledLayer explícita como primer intento para ver si marcaría la diferencia, pero no fue así, y así que dejé el código como está para publicar aquí. También hay una pérdida [tiledLayer release]; faltante en TilingView.

+0

¿Se las arregló para encontrar una solución? Estaba trabajando en lo mismo. –

+0

Sí, aumentar el tamaño del mosaico mejora el rendimiento significativamente. – jbm

+0

Entendido, acaba de agregar una nueva línea en el código: tiledLayer.tileSize = CGSizeMake (512, 512); Funcionó muy bien! Gracias. –

Respuesta

2

ya que su código contiene un par de errores y no puedo compilar el código, pero eché un vistazo al archivo PDF que se incluyó en el archivo y sé por qué su TilingView es lento.

Normalmente cuando dibuja una página pdf en CGContext usando el método CGContextDrawPDFPage:, todos los gráficos de texto y vectoriales se representaron y otras cosas, como gráficos normales en el PDF, simplemente se dibujaron y almacenaron en caché. Por lo tanto, no importa cuán grande sea el archivo PDF, pero sí importa si tiene graficos vectoriales en su PDF. Parece que tienes algún gráfico vectorial en tu PDF y también algunas ecuaciones matemáticas, esa es la razón por la cual es lento. Le sugiero que pruebe con otro archivo PDF que no contenga gráficos vectoriales y vea si es más rápido.

Saludos

Zheng

+0

Zheng, gracias por su respuesta. En mi computadora, el código se compila y se ejecuta con el último SDK de iOS 4.0.2. Y, por lo que respecta al contenido del archivo PDF, desafortunadamente no puedo elegir qué PDF mis usuarios deciden tratar de ver, simplemente debo hacer todo lo posible con cualquier documento PDF válido. – jbm

1

conjetura de que no deben tenerse con cualquier tipo de autoridad: PDF es un formato basado en vectores para la mayoría de los documentos (con exclusión de los que simplemente sirven de embalaje para las imágenes TIFF incrustados) . Así que cuando coloca el PDF como el PhotoScroller, básicamente le pide al teléfono que escale y rasterice todo el PDF (al menos la página dada) para cada mosaico individual. Entonces, en lugar de pintarlo una vez como lo harías con un solo CATiledLayer, lo haces varias veces para cada resolución. Dado que el PDF es un formato escalable en sí mismo, debería poder renderizar toda la vista una vez para cada página/escala.

Actualización: Habiendo pasado por esto yo mismo, el ejemplo de PhotoScroller tiene algunos problemas de lógica que lo hacen muy lento. Básicamente, renderiza cada ficha en 1/zoomScale, luego las escalas vuelven a bajar a zoomScale. Por lo tanto, si el zoom está en .5 se representa en 2x y luego se reduce a 0.5x. Muy lento y poco eficiente.

+1

de acuerdo, y el CATiledLayer debería ocuparse de eso para usted, ¿no? Sería bueno tener algún resultado de diagnóstico, o incluso una API de delegado de esa clase para hacernos saber cómo se comporta el almacenamiento en caché, de acuerdo con las propiedades que establecemos: tamaño del mosaico, detalle, sesgo de detalle. Supongo que necesitan espacio para modificar el algoritmo. – jbm

Cuestiones relacionadas