2010-06-28 4 views
4

OS의 이전 버전에서는 존재하지 않았던 iOS 4에서 CGContextDrawLayerAtPoint를 호출 할 때 성능 문제가 발생합니다.iOS 4.0의 CGContextDrawLayerAtPoint에서 Perfromance 문제가 발생했습니다.

drawRect 호출 중에 CGBitmapContextCreate로 만든 비트 맵 컨텍스트에서 내 뷰의 컨텍스트로 복사 한 레이어를 복사하고 있습니다. 보기와 비트 맵은 같은 크기입니다. 내가 OS 3.2을 실행하는 장치에보다 CGContextDrawLayerAtPoint에 더 많은 시간을 보내고있어 나타내는에

CGBitmapContextCreate(NULL, width, height, 8, width * 4, genericRGBSpace, kCGBitmapByteOrder32Host | kCGImageAlphaNoneSkipFirst); 

상품 :

비트 맵

을 만들었습니다. 동일한 코드가 3.2 쇼 시간이 훨씬 낮은 비율이

argb32_image_mark_rgb32 
argb32_image 
ripl_Mark 
ripl_BltImage 
ripc_RenderImage 
ripc_DrawLayer 
CGContextDelegateDrawLayer 
CGContextDrawLayerAtPoint 

에서 실행되는 반면

argb32_sample_argb32 
argb32_image_mark 
argb32_image 
ripl_Mark 
ripl_BltImage 
RIPLayerBltImage 
ripc_RenderImage 
ripc_DrawLayer 
CGContextDelegateDrawlayer 
CGContextDrawLayerAtPoint 

: 사실 스택 추적은 시간의 높은 비율을 고려하여 다음과 같은 스택 추적을 나타냅니다. arg432_sample_argb32가 iOS 4에서 호출되는 이유와 그 작업이 정확히 무엇인지 잘 모르겠습니다. 기존 데이터를 새 버퍼로 샘플링할까요? 왜 이것이 필요한지 나는 모르겠다. 뷰와 비트 맵의 ​​크기가 같고 크기 조정이 수행되지 않았습니다.

이것에 대한 통찰력은 인정 될 것입니다.

답변

0

글쎄, 아무도 이에 대한 통찰력이 없었기 때문에 우리 이론과 우리가 끝내었던 것을 자세히 이야기 할 것입니다. 이 이론은 iOS 4가 다른 화면 해상도를 처리해야하기 때문에 블리 팅에 대해보다 "일반화 된"방식을 취하고 있으며 그보다 훨씬 비효율적이라는 이론입니다.

결국 문제가되지 않습니다. 속도가 느려지고 처리해야합니다. 우리는 중복해서 복사하는 장소가 있다는 것을 발견했기 때문에 복사해야하는 양을 줄일 수있었습니다. 이것은 우리에게 필요한 속도를 우리에게 샀다.

관련 문제