Hi Allan, On Fri, Mar 21, 2008 at 3:22 PM, Allan Schaffer <[EMAIL PROTECTED]> wrote: > I was staying out of this but I think the "vendor lock-in" point is > being blown out of proportion. > Now, if it's simply a matter of OSS religion or OS allegiance for you, > then fine, read no further. > > On Mar 20, 2008, at 10:21 PM, Mike Weiblen wrote: > > Except for vendor lock-in, IMHO Apple would be insane to "require" > > it of applications in the future. > > Let's be very clear. Apple is doing no such thing.
Nor did I say they were. I was refuting an assertion of the original poster: <quote> I guess we're not far from a "suggest" becoming a "require" in the future. </quote> tortured syllogism: - Major premise: Requiring macros would be bad - Minor premise: Apple is not bad - Conclusion: Apple will not require macros. Agreed? :-) Apologies if the original phrasing offended ... > All that said, I actually don't think the CGLmacros trick is something > that should necessarily be adopted by OSG. It's more intended for > legacy immediate mode apps and/or CPU-limited apps. Agreed. Macro tricks are fine if an app decides to use in the privacy of their own home, but middleware like OSG should not impose sideeffects (ABI breakage) of presuming to make that decision. ... > > In quality OpenGL applications, MakeCurrent() just isn't a > > bottleneck in the pipeline that needs fixing. > > Nonsense. Every vendor shipping an OpenGL implementation sees that > repeatedly looking up the context in OpenGL entry points adds up, > particularly for immediate-mode apps. Instead of "quality" some other shorthand for VBOs/GLSL/etc. As recommended, the preferred guidance of modernizing immediate-mode apps to VBO/etc addresses much worse bottlenecks, and doesn't break ABI. ... > To the broader point, > I'd argue that the litany of little OpenGL design gotchas like this > one have weighed heavily into the redesigns of GL3. 100% total vehement agreement! And that's the crux: A truly portable solution to modern context management (as a candidate to be considered for integration by OSG) is a Big Hard Problem. The ARB is working very hard on a solution, and it's part of a major version bump in the API. The macro thing is a neat hack to gain a bit for low effort, it is platform-specific and has non-obvious ABI sideeffects. I dont think we're disagreeing? cheers -- mew -- Mike Weiblen -- Austin Texas USA -- http://mew.cx/ > On Mar 20, 2008, at 10:21 PM, Mike Weiblen wrote: > > Hi Raphael, > > > > I strongly agree w/ Robert on declining to incorporate that Apple > > extension into OSG. > > > > The problem with this "feature" is, while it seems to "enhance" the > > OpenGL API, it _totally_breaks_ the OpenGL ABI. > > > > There are many OpenGL shim libraries (such as gDEBugger, glIntercept, > > BuGLe and Chromium, to name just a few) that depend on mimicking the > > existing OpenGL dynamic library ABI. That entire class of tools is > > rendered unusable by the magic insertion of an additional parameter. > > > > For that reason, I believe this Apple extension should be actively > > *avoided* by any GL developers having any thoughts of portability. > > Except for vendor lock-in, IMHO Apple would be insane to "require" > > it of > > applications in the future. > > > > And I agree w/ Richard that this seems to be a "feature" of little > > practical merit. In quality OpenGL applications, MakeCurrent() just > > isn't a bottleneck in the pipeline that needs fixing. > > > > Not to speak for Robert, I suggest simple test for considering any > > OpenGL extension for OSG is: Would the ARB officially sanction the > > extension? I believe the chances in this case are 0. > > > > cheers > > -- mew _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
