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. We have a performance trick implemented in a macro in our GL headers that you can try if you want. If you don't try it, you're not using it. Most people don't even know about it (so they don't use it), and we surely don't require it in any way. Hopefully this should all be blatantly obvious since OSG has been on Mac OS X for some time now without using it. Your code does not change except for adding a #include and adding/ setting a global variable somewhere (yuck, I know). Obviously that would all be #ifdef/endif so it is only done on Mac. 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. It might be worth trying just to see if there's a speedup with OSG, but if not, it's moot. > 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. It's low % but is undeniable -- and this is what the CGLmacros trick addresses. 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. But back to the specifics. If you have immediate mode code, the first recommendation in our docs is to modernize and use VBOs/GLSL/etc. If not, we suggest including this macro to get a few % speedup. One of the code samples on our developer website (VBOBunnies I think) demonstrates the performance delta between plain immediate mode, immediate mode+CGLmacros, VBOs. > There are many OpenGL shim libraries (such as gDEBugger, > glIntercept, BuGLe and Chromium, to name just a few) That's true but the specifics might poke holes in this point. gDEBugger is only on windows, glIntercept only ships windows binaries, BuGLe isn't supported on Mac OS X, Chromium isn't on Mac OS X (to my knowledge), etc. The GL Debugger we ship works with it. And of course, this change would have no effect on the platforms where you'll find those tools. Allan ___________ Allan Schaffer Graphics Evangelist Apple 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 > > > > >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:osg-users- >> [EMAIL PROTECTED] On Behalf Of >> [EMAIL PROTECTED] >> Sent: Thursday, March 20, 2008 10:41 AM >> To: OpenSceneGraph Users >> Subject: Re: [osg-users] Mac OpenGL integration / CGLMacro.h >> >> While Robert makes a good and valid point about corrupting the API > (and >> reality distortion fields in general), I don't think the original >> poster >> adequately explained this "feature" of OpenGL on Apple platforms. >> >> All it amounts to is a #ifdef __APPLE__ and an extra include file in >> all the >> OSG headers (just like including gl.h) plus a single function call >> tucked >> away in the OpenGL initialization code. It doesn't change the OpenGL >> API as >> far as the source code or programmer is concerned. The original >> poster >> sort >> of made it sound like each OpenGL call now has an extra parameter >> passed >> in... which it does, but this is "hidden" by the macro header. No >> changes to >> OpenGL code required (unless you consider an extra header file an > undue >> burden and pollution of the API ;-). It does speed up each OpenGL >> call >> on >> the CPU side, and can help (God forbid) immediate mode code >> considerably. >> >> It would be fairly simple to add to OSG, albiet tedious, and Robert >> (who >> obviously is not a Mac user ;-) would have to test it, or have >> someone >> close >> to him test it (hundreds of files would be affected). >> >> Even though I am fully immersed in the Apple reality distortion >> field, >> I >> would have to express doubt however that it is worth the change. In > the >> age >> of batched geometry submission (as opposed to immediate mode), and >> the >> increasing reliance on shaders rather than the OpenGL state machine > the >> value of this feature over time get's increasingly smaller. I have > made >> this >> retro-fit many time to my own projects without any problems... what I >> have >> failed to see however is any significant performance benefit to well >> written >> OpenGL code in the first place. >> >> Richard >> >> >> >> Robert Osfield writes: >> >>> On Thu, Mar 20, 2008 at 1:35 PM, Raphael Sebbe >> <[EMAIL PROTECTED]> wrote: >>>> thanks for answering. I understand your point regarding cross >> platform >>>> complexity. However, I am pretty convinced that passing the context >> to >>>> drawing functions makes sense these days, especially considering > the >> many >>>> contexts and threads running in parallel, and I don't get this as a >> vendor >>>> lock-in strategy, although this can be a side-effect of course. >>> >>> Ahhh the Steve Job reality distortion field... >>> >>> The vendor lock-in comes from getting developers to start off on >> Apple >>> then get them hooked on non portable API's, then come the day when >> you >>> want to port to another platform you whole architecture is tied up >>> around these non portable API's. Porting to other platforms > becomes >>> a prohibitive task. >>> >>> Apple and Microsoft do it all the time. Think how non standard all >>> MS's and Apple's API's are. They even making porting back to >> previous >>> versions of their OS's hard. MS's did 3D graphics with Direct3D >>> rather than the industry standard OpenGL purely for lock-in and hey >>> now Apple are tying to use OSX specific extensions to OpenGL that do >>> the same thing. MS and Apple offer sweeteners, make it easy to >>> sudducced by their API's with slick and "plausable" marketing and >>> before you know you're hooked and tied in. >>> >>> The OSG is so portable because I and other resist such vendor lock- >> in, >>> any platform specifics are kept well encapsulated enabling the end >>> users to easily move between platforms. Portability is sweet for a >>> project like the OSG not only because it gives freedom to end users, >>> but also means that it's diverse development community can help > each. >>> Windows user writes and OpenGL extension that is portable, submits, > I >>> come it under Linux, then others under OSX, then Solaris, etc, the >>> same works the other way. All users get to benefit from each other. >>> >>> Extensions like Apple's don't benefit anyone except Apple users tied >>> to the Apple platform. Integrating it into the OSG or other >>> applications/API's harm *all* other platforms because it takes >>> developers resources away from things that benefit all platforms, it >>> adds complexity so adds maintenance burden which further weighs down >>> the whole product/project/community To be successful as a software >>> engineer you have to be vigilant about these issues, if you aren't >> you >>> can get sucked in by the slick marketing and end up forgetting that >>> you're developing software for the benefit of all your users, not to >> a >>> particular vendor. >>> >>> Robert. > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
