Hi Rui, On Mon, Jul 18, 2011 at 12:51 PM, Wang Rui <[email protected]> wrote: > I agree it should be better if we could have a CEGUICamera which > manages the GUI interface and events. But I just wonder if using node > event callbacks is less efficient than using GUIEventHandlers > sometime. At least it requires an extra traversal of the scene graph > which may not happen if there are no event callbacks.
There is always an event traversal, like there is always an update traversal. Both traversal types have a mechanism for cutting short the traversal of subgraph if that subgraph doesn't contain any event and updated callbacks. So.. it's perfectly efficient to use an event callback on a node. >> One thing I haven't worked out yet is why the initializeControls() >> exists, it looks from the context as if CEGUI requires a valid >> graphics context event to create and initialize objects. Also from >> reading the code, outwardly it looks like CEGUI relies entirely on >> singletons to manage all data structures, so that the OSG classes are >> there purely to provide a means for calling the CEGUI for a thread >> with a valid grpahics context, the OSG classes/objects aren't directly >> connected to specific CEGUI instances, rather call CEGUI via it's >> singletons. Am I reading it correctly? >> > > Yes. CEGUI must have a valid OpenGL context before initializing, so I > have to force creating all the CEGUI data at the first time we run > into drawImplementation(), and leave a virtual method > initializeControls() for end users to customize their own UI elements. Crappy CEGUI design/implementation decision there. Stuck in the world of SDL based single threaded/single context applications... What you could have is initialize callback that gets called by the CEGUI node the first time it's traversed in the draw traversal. The initialize callback could be lighter weight than the idea od subclassing from a full blown class where used could get confused about what they need to do. > There are no direct connections between CEGUI controls and OSG classes > in this example. But the idea is interesting to me: why don't we have > some abstract classes in the future, like osgWidgets::Button and > EditBox, and implement them within an osgdb_cegui plugin? But this > requires a huge modification to the osgWidgets namespace (or create a > new one) and maybe we have to discuss with Jeremy Moles and somebody > else before breaking the earth. I don't think making the osgWidget library work as a plugin based scheme would be sensible. The idea of osgWidget is that it's a native OSG implementation that has all the capabilities of the OSG. It's design and implementation falls a little short in several areas but that's the idea. Robert. _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
