CGBitMapContext: high performance pixel layout is ARGB, BGRA, or other on iPhone/iPad when vending CGImageRefs

[David Hoerl]

Tried to jam all the keywords into the subject line as I could not find
the answer to this in the archives, nor googling, even though I know I
recently saw it somewhere.

I'm talking about vending big images so this could potential make a big
difference. I could test on my iPhone 4 running iOS 5, but would not
know for sure if what I measure is actually representative of the
community of devices or not, nor whether I should use one format going
forward because "its the best way to do it" (ie directive from Apple).

So, what IS the best format to use when vending CGImageRefs destined to
be shown in a view?

Thanks!

David
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartz-dev mailing list (Quart...@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/quartz-dev/quartz-dev-garchive-50095%40googlegroups.com

This email sent to quartz-dev-g...@googlegroups.com

[Justin Spahr-Summers]

I can't say anything about an official recommendation, but I've found ARGB in 32-bit host byte order to easily be the most performant format for bitmap contexts. Profiling it in the Core Animation instrument also reveals that it doesn't have to do copying (including any channel swapping) before displaying.

-- 

Justin Spahr-Summers

https://lists.apple.com/mailman/options/quartz-dev/justin.spahrsummers%40gmail.com

This email sent to justin.sp...@gmail.com

[David Hoerl]

On 2/11/12 1:38 AM, Justin Spahr-Summers wrote:
> I can't say anything about an official recommendation, but I've found
> ARGB in 32-bit host byte order to easily be the most performant format
> for bitmap contexts. Profiling it in the Core Animation instrument also
> reveals that it doesn't have to do copying (including any channel
> swapping) before displaying.
>
> --
> Justin Spahr-Summers

OK - just to cloes of this thread for good. What I finally ended up with
were these flags for the context:

(kCGImageAlphaNoneSkipFirst or kCGImageAlphaFirst) |
kCGBitmapByteOrder32Little

My project now has a both Quartz and libjpeg intermixed. The flags I
need to use for libjpeg to get it to write data out in a similar order
use "BGRA".

So, in any case, if you look at the raw data its laid out B, G, R, A, B,
G, R, A, ...

The Quartz documents never make it clear if the host order affects the
alpha flag or not. Well, it would appear they do since my interpretation
of (kCGImageAlphaFirst | kCGBitmapByteOrder32Little) is that alpha is
first when the host order is "big endian", thus the bytes are laid out
BGRA as would be consistent with the libjpeg.

I guess what I need to do is think of that alpha flag as a prefix or suffix:

kCGImageAlphaFirst -> ARGB
kCGImageAlphaLast -> RGBA

Then the host order is applied to the result. I sure hope I can remember
this the next time I need it :-)

David

PS: I thought I had it right, then saw a "CGSConvertXRGB8888toRGBA8888"
show up in a crash (as Justin said would happen), and knew I'd not
gotten it right the first time.

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartz-dev mailing list (Quart...@lists.apple.com)
Help/Unsubscribe/Update your Subscription: