On Jan 7, 2010, at 5:36 PM, David Blanton wrote:

>       CGColorSpaceRef colorSpace;
>       colorSpace = CGColorSpaceCreateWithName(kCGColorSpaceGenericRGB);
>       CGDataProviderRef provider = CGDataProviderCreateWithData 
> (NULL,m_bitmap.m_array, 4*m_bitmap.m_pixelsx*m_bitmap.m_pixelsy, NULL);
>       CGImageRelease(m_CGImageRef);
>       m_CGImageRef = CGImageCreate(m_bitmap.m_pixelsx, m_bitmap.m_pixelsy, 8, 
> 32, 4*m_bitmap.m_pixelsx, colorSpace,  
> kCGImageAlphaNoneSkipFirst|kCGBitmapByteOrder32Host, provider, NULL,YES, 
> kCGRenderingIntentDefault);
>       CGImageRetain(m_CGImageRef);
>       CGColorSpaceRelease(colorSpace);
>       CGDataProviderRelease(provider);
> 
> Clearly I have kicked NSBitMapImageRep under the bus as the above gives what 
> I am looking for.
> 
> The performance issue comes from the fact the user will be dragging this 
> bitmap around so I a regenerating m_bitmap.m_array  constantly.


The specific performance issue with using CGBitmapContextCreate() with 
CGBitmapContextCreateImage() to wrap a buffer of data is that in order to 
preserve the semantics of a CGImageRef, CGBitmapContextCreateImage() needs to 
mark the buffer pointed to by the bitmap context as copy-on-write. This 
requires a call into the kernel, which is a relatively expensive process. This 
process is typically cheaper than actually copying the bytes around, but since 
you aren't actually using the context it is more expensive than going the 
direct route.

However, since creating an image directly via CGImageCreate() is nearly 
identical to creating a bitmap context, it is the preferred solution since it 
avoids a call into the kernel. The only significant difference is the need to 
create a data provider, but doing that is straightforward. In the end, it is 
about the same number of lines of code to create the image directly, and you 
avoid the call into the kernel.
--
David Duncan
Apple DTS Animation and Printing

_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to