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
