Sorry, I know I'm late to this thread, especially since the Carbon stuff is implemented. I've been swamped with work (and I'm still behind), but I wanted to chime in on a few things with respect to Cocoa. (I'm ultimately interested in seeing a native Cocoa viewer too.)
Main Loop and Fullscreen: So polling is frowned upon on the system. There are lots of obvious reasons for this plus some that may not be so obvious. I am under the impression this is a strong reaction to the Mac classic roots where the OS had no pre-emptive multitasking and ported (Carbon) programs to OS X would suck up all the processor power. Power management has become a more important issue of late as about half of the number of computers Apple sells are mobiles. However polling is possible in Cocoa. (FYI, SDL actually does this as a real world example.) Setting up polling in Cocoa is off the beaten track for most Cocoa developers. NSApplicationMain is a convenience API that sets up a bunch of things, but could be bypassed in favor of dealing directly with API calls it uses. But I think it would be handy to have a common Init() function in the API to setup one time things like this if needed (not per-window instance). (For some reason, I expect Windows to benefit from something like this too.) With respect to fullscreen, Apple actually has a Cocoa fullscreen example here: http://developer.apple.com/samplecode/NSOpenGL_Fullscreen/index.html There is also a document here: http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaDrawingGuide/AdvancedDrawing/chapter_9_section_4.html Things to note: 1) Fullscreen leverages Apple's fullscreen APIs. For the platform, I think this makes much more sense than creating a large borderless window and hiding the menu and dock ourselves. I suspect behind the scenes, Apple is doing this very thing for us but can also apply optimizations and may better remember to handle corner cases like Expose. 2) CGL and Cocoa are not mutually exclusive. Cocoa (and Carbon) are built on top of "Core" components like Core Foundation and Core OpenGL. But Core Foundation/CGL is not sufficient to build a full-fledged application. Cocoa and Carbon provide that part of the functionality. They are meant to work together. In many places, Cocoa tries to provide the most used functionality in its APIs, but for places that can't be expressed concisely in a Cocoa API or are not implemented yet, you are expected to drop down a layer. So I don't think it makes much sense to consider SimpleViewerCarbon and SimpleViewerCGL separate implementations that need to be switched at runtime. They should work together. (Though we might be able to factor out some code so the CGL stuff is common to SimpleViewerCarbon and SimpleViewerCocoa.) 3) In the above example code, the code actually introduces a polling system when the program enters Fullscreen mode. This might be the most reasonable compromise if we must provide a polling API. The down side is you do have two different locations to implement event handling. (But I do want to point out that according to gossip on the web, Leopard will be providing a Fullscreen mode that is tied to Core Animation. I suspect though that it won't look anything like the polling technique in the demo above given that everybody frowns upon polling. I also suspect the event handling would be unified with the normal system, though I don't know for sure.) -Eric _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
