> Would not the CVOpenGLBuffer have the same issues that the CVopenGLTextureRef > have, ie, relying on a valid shared CGLContext that both the QCRenders share ?
Probably -- they're both similar in that regard. Looking closer, there aren't any initializers for CVopenGLTextureRefs. Perhaps that's why it doesn't work? (Using SPI is annoying, even internally -- means more code babysitting and more breaking when some other framework changes.) > Regardless - in this case - the two QCRenderers were initted with the same > CGLContextObj, so the texture output ought to be valid for the secondary > QCRenderer (same CGLContext so the GLuint generated ought to be ok). > Furthermore, even if using a single CGLContext and a single QCRenderer, and > without forwarding the object outputted from valueForOutputKeyL ofType to any > other QCRenderer, simply using the debugger sometime after the QCRenderer has > renderedAtTime, and introspecting the value for the various valid / listed > output keys, CVOpenGLBuffer always returns a valid object, the > CVOpenGLTextureRef is never an actual object, it always returns nil, so it > never even 'gets to' the issue of possibly not being a valid texture in a > secondary QCRenderer (via a shared CGLContext, the same, or what have you). > It simply never was a valid texture. I was basically saying this: "Feature X may not work intentionally because there are situations where it cannot work". You see this type of justification for a number of things in QC: Multisampling isn't available on render in image because not all GPUs support it (among other things). This rationale isn't uniformly applied (higher bit depths are offered, despite spotty GPU support), but it's a plausible reason for an omission. After looking at the APIs, I'm more confident that it's because CoreVideo doesn't really provide any initializers for said object. Previously I was simply making a conjecture (I wasn't here for the decision making ;) I totally get the "for debugging purposes" thing -- I wasn't trying to say "it might not work because of the situation you're giving it", I was trying to say "it might not work at all because you can give it situations where it cannot". The difference is subtle, but critical :) > Im curious about "so it would work, but only based on luck" 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. This was all talking about texture sharing abstractly, by the way, not your particular scenario. > If you create two CGLContext with the same pixel format and mark one, during > its creation, as being shared with the other, as long as it was successfully > made, by definition OpenGL objects will be able to be shared, and thus > CVOpenGL objects - just like any other GL object correct? SO I dont see why > luck would happen, it should be by design no? See above. > Thanks so much for any info. I guess my main question is under what > circumstances is a CVOpenGLBuffer (which is stated in the docs to be a > wrapper over a pbuffer), going to behave differently with regards to share > groups and contexts than a texture? (Honest question, this is not an attempt > at wise-ass-ery :) :) As long as the contexts are shared by design, there's no luck involved. (Again, see above). If they're only shared because some random snippet of code happened to share them, and you might revise that code at a later date, it works now but only by luck, and might not if you change it. You personally have a grasp of what's at play here, so you understand cases where it will and won't work. But for someone gluing random code together, working/not working would seem arbitrary and magical, and that's why I mentioned potential "operation-by-luck" instead of "operation-by-design" (So, not really for you, but for lurkers in general :) -- Christopher Wright [email protected]
_______________________________________________ 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]
