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
