site_archiver@lists.apple.com Delivered-To: pro-apps-dev@lists.apple.com Darrin On Feb 25, 2009, at 4:04 PM, Darrin Cardani wrote: Darrin On Feb 25, 2009, at 12:00 PM, Matt Rhodes wrote: This is Motion. I haven't checked FCP. Thanks. m On Feb 25, 2009, at 11:16 AM, Paul Schneider wrote: Hi Matt, - Paul On Feb 24, 2009, at 12:52 PM, Matt Rhodes wrote: Hey Team. Thanks. Matt Rhodes Zaxwerks, Inc. _______________________________________________ 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/pschneider%40apple.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/dcardani%40apple.com -- 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/dcardani%40apple.com -- 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... OK, I may have been too hasty in my recommendation below. I apologize.
From talking to some of the other engineers who worked on this before me, it seems that the shared context is actually created in a way that makes it compatible with the current context. At the time we added the sharedContext variable, we did so because we thought that it would be needed by 3rd party developers in order for you to create pbuffers that shared with the context Motion was rendering to. It turns out we could have just recommended using CGLGetCurrentContext (). It's not always the same context as the shared one, but because they both have the same parent, it doesn't matter. They get you the same thing. So it seems at this point that you can use either. But it's probably safest for forward compatibility to use the shared context in case we ever change how that works. No, I can't think of a reason why you would ever want to use the current context. It's likely that doing so will either not produce any noticeable results or will produce bad results. That context is probably whatever context was being rendered to before you were called, and may not even have been set by the application. (I'm not positive of that, but my point is don't assume it has any particular significance.) I'd like to know if there's a reason to use the current context in Motion vs. the renderInfo.sharedContext. Is this in FCP, Motion, or both? As far as I know, the contexts should be the same in FCP. Can someone tell me the difference between the current context (derived from CGLGetCurrentContext())
and renderInfo.sharedContext at the start of -renderOutput? From what I can tell, they're different. I realize renderInfo.sharedContext may be NULL when rendering to a bitmap. This email sent to pschneider@apple.com This email sent to dcardani@apple.com This email sent to dcardani@apple.com This email sent to site_archiver@lists.apple.com