site_archiver@lists.apple.com Delivered-To: pro-apps-dev@lists.apple.com On Feb 4, 2008, at 3:12 PM, Steve Christensen wrote: As of 3.x, yes. I think there were cases in 2.x where they were not. Darrin -- Darrin Cardani dcardani@apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.ap... On Feb 4, 2008, at 8:21 AM, Darrin Cardani wrote: Correct. Input and output should always be the same bit depth and channel order. Note that there is a bug in Motion in which the output bitmap will claim to be RGBA, when it's really ARGB, just like the input (when working in software). It's safe to ignore it and output ARGB. 1. So the input bitmaps are advertised with the correct channel order? 2. Is this separate from what the formatsFloatRGBABitmapsAsARGB selector in FxHostCapabilities returns? Sort of. In Motion 2.x, we claimed that float bitmaps were RGBA, but they were really ARGB. At the time, I thought it only affected input bitmaps and bitmaps obtained from the parameter retrieval API or temporal API. I didn't realize it also affected output bitmaps. In Motion 3.x and later, you should no longer need to check that flag. It's only in 2.x that it's an issue. 3. Or in the Motion case are all bitmaps ARGB, independent of the pixel depth? I want to say that all bitmaps should be ARGB independent of pixel depth. Let me know if you find that not to be the case. This email sent to site_archiver@lists.apple.com