Hrm. My immediate response (and I am sort of reading in to all of this a bit I admit, so take this with a grain of salt), is that APIs should be developed for people who aren't glueing random pieces of code together but for those who design based upon the APIs and limitations/considerations of the underlying technology. For what its worth id rather have an API that "sometimes works" but is incredibly useful, (meaning, a program is designed to use it, rather than random code snippets glued together that may/may not work...).
I'd wager many other folks would opt for a caveat in the docs stating "make sure that if you pass the output of CVOpenGL objects to QCRenderers created with different contexts, that those contexts must be shared (see the Mac OpenGL Developers Guide topic on sharing contexts for more information), rather than having an API that is limited /designed to be used only by.. pasting code snippets together :), and removes some very useful features for the sake of 'luck' I hope you read that in a "non facetious, playful tone" rather than... well, you know :), Being able to get CVOpenGLTextureRefs (or even Gluint texture IDs) out of QC is (would be?) amazingly useful for all sorts of scenarios. I may go so far as to install 10.5.8 somewhere and test this, because I recall using this functionality at some point, but I may be remembering incorrectly. Thanks again Chris for the off hours info :) On Sep 19, 2010, at 11:38 PM, Christopher Wright wrote: > In a hypothetical world, sharing GL textures by name between two different > objects with two different contexts isn't going to work unless the two > contexts are shared. If you happen to have the contexts share, reusing the > name will work, but only due to luck unless shared contexts were explicitly > part of the design. There are times where people will design applications > that initially utilize shared contexts (for simplicity in setup code, for > example), but then move to non-shared contexts for GPU feature reasons (MSAA, > different bitdepths, etc). Such a change can suddenly "break" code that > passes texture names along not due to an inherent structural change, but an > implementation detail. In that case, it would work initially (with shared > contexts) only by luck, not design. > _______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to [email protected]
