12

Sto generando un mucchio di tessere per CATiledLayer. Occorrono circa 11 secondi per generare 120 tessere a 256 x 256 con 4 livelli di dettaglio su un iPhone 4S. L'immagine stessa si adatta entro 2048 x 2048.Qualche modo per codificare un PNG più veloce di UIImagePNGRepresentation?

Il mio collo di bottiglia è UIImagePNGRepresentation. Occorrono circa 0,10-0,15 secondi per generare ogni immagine 256 x 256.

Ho provato a generare più riquadri su diverse code di sfondo, ma questo riduce solo a circa 9-10 secondi.

Ho anche provato utilizzando il framework ImageIO con codice come questo:

- (void)writeCGImage:(CGImageRef)image toURL:(NSURL*)url andOptions:(CFDictionaryRef) options 
{ 
    CGImageDestinationRef myImageDest = CGImageDestinationCreateWithURL((__bridge CFURLRef)url, (__bridge CFStringRef)@"public.png", 1, nil); 
    CGImageDestinationAddImage(myImageDest, image, options); 
    CGImageDestinationFinalize(myImageDest); 
    CFRelease(myImageDest); 
} 

Mentre questo produce file PNG più piccoli (vincere!), Ci vogliono circa 13 secondi, 2 secondi più di prima.

C'è un modo per codificare un'immagine PNG da CGImage più veloce? Forse una libreria che utilizza l'estensione ARM NEON (iPhone 3GS +) come libjpeg-turbo?

C'è forse un formato migliore del PNG per il risparmio di piastrelle che non occupa molto spazio?

L'unica opzione valida che sono riuscito a ottenere è quella di aumentare le dimensioni della piastrella a 512 x 512. Questo riduce di due volte il tempo di codifica. Non sono sicuro di cosa farà alla mia vista di scorrimento. L'app è per iPad 2+ e supporta solo iOS 6 (utilizzando iPhone 4S come base di riferimento).

risposta

4

si scopre il motivo per cui UIImageRepresentation stava eseguendo così male era perché era decomprimere l'immagine originale ogni volta anche se ho pensato stavo creando una nuova immagine con CGImageCreateWithImageInRect.

È possibile visualizzare i risultati di Strumenti qui:

enter image description here

Avviso _cg_jpeg_read_scanlines e decompress_onepass.

I era forza-decompressione dell'immagine con questo:

UIImage *image = [UIImage imageWithContentsOfFile:path]; 
UIGraphicsBeginImageContext(CGSizeMake(1, 1)); 
[image drawAtPoint:CGPointZero]; 
UIGraphicsEndImageContext(); 

La tempistica di questo era circa 0,10 secondi quasi equivalente al tempo impiegato da ciascun UIImageRepresentation chiamata.

Ci sono numerosi articoli su Internet che consigliano di disegnare come un modo per forzare la decompressione di un'immagine.

C'è un articolo su Cocoanetics Avoiding Image Decompression Sickness. L'articolo fornisce un modo alternativo di caricamento dell'immagine:

NSDictionary *dict = [NSDictionary dictionaryWithObject:[NSNumber numberWithBool:YES] 
               forKey:(id)kCGImageSourceShouldCache]; 
CGImageSourceRef source = CGImageSourceCreateWithURL((__bridge CFURLRef)[[NSURL alloc] initFileURLWithPath:path], NULL); 
CGImageRef cgImage = CGImageSourceCreateImageAtIndex(source, 0, (__bridge CFDictionaryRef)dict); 
UIImage *image = [UIImage imageWithCGImage:cgImage]; 
CGImageRelease(cgImage); 
CFRelease(source); 

E ora lo stesso processo richiede circa 3 secondi! L'uso di GCD per generare piastrelle in parallelo riduce il tempo in modo più significativo.

La funzione writeCGImage richiede circa 5 secondi. Poiché le dimensioni del file sono più piccole, sospetto che la compressione zlib sia a un livello più alto.

Problemi correlati