Hi All, I am currently beavering away on the X11 side to the new osgViewer, implementing a GraphicsWindowX11 to help open up the graphics windows. Now I can open up windows and get events across multiple screens and able to get a little bit nearer to the multiple graphics context/multiple camera functionality of osgProducer/Producer. Still lots of work left to do on polishing the event handling, and supporting multi-threading, and with the general layout and management of the viewer classes.
My plan is to get the X11 side working pretty well and have bulk of the viewer library functioning in a usable, then seek assistance from the community for development of GraphicsWindowWin32 and GraphicsWindowCocoa support for Windows and OSX respectively. I don't have have a windows dev machine, or an apple, or the skills in Win32 and OSX to help out in this direction so I'll really need assistance. Please come forward if you fancy helping out in this effort. The osgViewer::GraphicsWindow (for windows) and osg::GraphicContext (for pbuffers) base classes will define the methods that are needed to be implemented - basically all the virtual methods. The GraphicsWindow is a subclass of GraphicsContext and adds event handling and other windowing specific features ontop GraphicsContext. Most of the time we'll just be manage concrete instances of GraphicsWindow, but for pbuffers the windowing specific features are inappropriate so it is ideal to just create a GraphicContextX11, GraphicsContextWin32, GraphicsContextWin32 to help with pbuffer management, so I'll be looking for implementations of these as well. I haven't yet implemented a GraphicsContextX11 but will do soon. Its a lower priority than the GraphicsWindow ones as its these that will provide the bulk of usage. There is also scope for many other GraphicsWindow implementations, such as QT, WxWindows, FLTK, Fox, MFX, ActiveX etc etc. These aren't as critical as the X11, Win32 and Cocoa implementations though, and won't need to provide all the functionality required of the these main three - i.e. multiple screen and pbuffer support appears lacking most of these higher level windowing toolkits. The design of osgViewer is such that we will be able to mix and match GraphicsWindow implementations, so you could use the X11/Win32/Cocoa implementation for things like pbuffers and immersive stereo visualization and then you're favorite high level Windowing toolkit elsewhere in your app. Also new GraphicsWindow implementations could also be provided at runtime via plugins. This now brings me on to the feedback that I really want right now - should the osgViewer by default provide the basic GraphicsWindowX11, Win32 and Cococa, or should these be loaded from plugins at runtime? Originally I had felt that plugins was the way to go, as this is certainly the most flexible, and light weight (you only load what you need) but... plugins can make distribution of apps more difficult, and it also complicates the static build further than it is already. Right now my currently inclination is to build in GraphicsWindowWin32 under Windows, GrahicsWindowX11 under unices and GraphicsWindowCocoa under OSX. The practicalities of this is simply that each of these platforms would compile a GraphicsWindowWin32.cpp etc as appropriate for its platform, so its really just a makefile/project file issue. I'm also inclined not to offer windowing plugins as standard, just to keep things simple. I realise this is a big topic, and I've haven't fleshed out too much yet, but I'd love your feedback. I will of course be posting more messages about osgViewer in coming days/weeks, right now I do need some feedback though: - plugins for basic windowing support? - or build directly into osgViewer? Robert. _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
