Re: Best 'native' formats for NSImage and NSSound?
Re: Best 'native' formats for NSImage and NSSound?
- Subject: Re: Best 'native' formats for NSImage and NSSound?
- From: Benjamin Stiglitz <email@hidden>
- Date: Tue, 02 Sep 2008 15:50:52 -0400
In running Shark on my app recently I noticed that by far, my app
spent most
of its time in: CGSConvertBGR888toRGBA8888.
I'm having trouble understanding what this means. It appears that
CoreGraphics is having to convert some of my non-alpha channel
images to
have an alpha, and perhaps re-order the bytes? But shouldn't these
conversions only occur once, when CG realizes it needs this additional
channel?
NSImage should only be doing the conversion once unless you’re
continually reloading the image from its original file. You should see
an NSBitmapImageRep, in the target drawing context’s format, attached
to the image after drawing. I don’t believe the sub-rect drawing
behavior is any different. It’d be useful to see the relevant part of
your Shark trace.
My app is re-using the same NSImages each frame, simply compositing
various sub-rects from the original large images.
And also, seeing how much work NSImage is having to do, it got me
wondering,
are there any image/sound file formats which require 'less work' on
the part
of NSImage and NSSound? In terms of loading the initial data,
unpacking the
bytes, etc.
I was wondering if switching to .TIFF or .AIFF (or any other
formats) could
possibly provide a performance boost?
There’s no real guarantee for images, since the compositing buffer
format isn’t specified, and is therefore subject to change at any
time. If you’ve got a downloadable app, you may want to optimize for
file size anyway. (The same advice applies for sounds.)
-Ben_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden