Hi Eric, Thanks for the insights. Its funny that Apple "frowns" upon polling for events, it points to be entirely event driven in focus, for real-time graphics your absolutely do not want to be event driven. Perhaps Alan Shaffer can winkle some real-time graphics know how into Apple ;-)
I do want to support both event driven and frame driven apps with osgViewer though, right now only SimpleViewer can do both - while it is typically used event driven but be used frame driven is one adds the polling of events. The current Viewer and CompositeViewer are set up for fame driven so they do a checkEvents on each GraphicsWindow from inside the main loop. Making them event driven is something that should be possible, but might need a few additions. The first test will be creating an event driven example using Viewer or CompositeViewer, this is something on my TODO list for the next few weeks. Robert. W.r.t SimpleViewerCarbon vs SimpleViewerCocoa, my hope is that we won't need wither, we'd just have a GraphicsWindowCarbon (as we have) and a GraphicsWindowCocoa, and these windows would then be usable with any of the viewer variants. For instance since we now have a GraphicsWindowCarbon all the examples, including the new CompositeViewer example work just fine out of the box, there isn't any need for a special example showing how to use Carbon. My hope is for Cocoa we can get to the same level of reusability. W.r.t full screen mode, its keeps things simpler to have just one graphics context to manage within one GraphicsWindow - this is reason for making the full screen window borderless and hiding the menu/docking bar. Stephan and I discussed the possibility of having a raw full screen mode GraphicsWindow that can't be resized away from full screen, this would allow you to use the native full screen without any compromises. I don't know how the API's you talk of effect this though. Robert. On 1/16/07, E. Wing <[EMAIL PROTECTED]> wrote:
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 osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
_______________________________________________ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
