Thanks, Mike, for putting it in this perspective. Now that you mention it, we agree that this would break things that we use.
This raises an issue found recently as we were building OSG on Solaris. On our Solaris machines, /usr/include/GL/gl.h has, near the bottom, a bit of code like: #ifndef SUN_OGL_NO_VERTEX_MACROS #ifndef LINUX #include <GL/glmacros.h> #endif /* LINUX */ #endif /* SUN_OGL_NO_VERTEX_MACROS */ glmacros.h contains defines for things like glVertex2f, calling a function from a function table and passing a current context in. This broke a bit of code in OSG that was defining a class with methods with the names of OpenGL functions. Those functions declarations had the Sun define applied, so wouldn't compile. Robert had to change the names of the methods. Maybe we should be compiling OSG with SUN_OGL_NO_VERTEX_MACROS. If I get time, I may try it both ways and see if I can compare. Thoughts from people who know more about this? thanks, andy -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Weiblen Sent: Friday, March 21, 2008 1:21 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Mac OpenGL integration / CGLMacro.h 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.or g _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
