| Aha! This provides an opening for me to re-ask a question that nobody answered on the QuickTime mailing list:
I'm trying to update our image processing code for Intel, and I'm using native byte ordering for pixel formats in GWorlds and CGImages. What happens for 64-bit pixels? There's no k64BGRAPixelFormat to match k64ARGBPixelFormat, so what should I be using on Intel? For Windows, we use k64ARGBPixelFormat, so we already have the swapping code in place, but I'd like to know the official position for the Mac.
Jerry On 28 Oct 2005, at 14:23, Daniel Jalkut wrote: Hi Miles. Larry is right that for the most part you don't have to worry about byte swapping at all. You will probably find this document illuminating, as it covers many if not all of the very specific cases where the Mac OS APIs will require your involvement to ensure a correct outcome:
Look in particular at the "Specific Scenarios" section. It's worth reading through the whole thing, though. The document was apparently written by Apple after experiencing most of the "developer scenarios" themselves over the past few years preparing for the switch.
Daniel
On Oct 28, 2005, at 5:44 AM, Miles Henderson wrote: Hi all, Do deprecated APIs provide byte swapping on the Mac Intel platform? For example, consider the following code: Rect bnds; PixMapHandle pm = GetGWorldPixMap(myport); if (pm) { bnds = (**pm).bounds; } After doing the above, will bnds contain the right values or do I need to perform a swap manually? If there are byte swapping issues with some but not all deprecated APIs, does anyone have a list of deprecated APIs that have byte swapping issues? Thanks and Regards, Miles Henderson OSX Engineer Raining Data UK _______________________________________________ Do not post admin requests to the list. They will be ignored. Help/Unsubscribe/Update your Subscription:
_______________________________________________ Do not post admin requests to the list. They will be ignored. Help/Unsubscribe/Update your Subscription:
|
