Hi Paul, On Thu, Feb 26, 2009 at 7:53 PM, Paul Martz <[email protected]> wrote: > I can think of a least two ways to support multiple backends without > sacrificing performance. > > 1) We generally acknowledge that a system of wrappers will provide > portability (to different backends) at the expense of performance. However, > a scene graph could be designed in such a way that it supports one backend > "close to the metal" and other backends using wrappers.... > > 2) Use a factory pattern.
With my own considerations of moving to an API agnostic scene graph the issue of performance is one that has loomed large in my mind. We absolutely want to avoid any performance degradation in this move for any of the targets - that's the gold standard which we should strive for. There are couple of elements to the performance side, first up is the cost of abstraction. Right now we have StateSttributes with a virtual function that calls OpenGL C functions to pass state to OpenGL. A refactor method system could in theory create the concrete classes for us that do the subclassing of the the interface and thereby work with just the exiting virtual function. To do this we have to change the way we construct scene graphs. Such an approach would also limit us to only use one type of GraphicsContext in an application, which isn't too much of a limit. A second element to performance is that of multi-threading. Right now we don't buffer the scene graph so the current DrawThreadPerContext/CullThreadPerCameraDrawThreadPerContext has to hold back the next frame till all dynamic state + drawables are dispatched. This means we are limiting the opportunity for parallelism. So.. how do we solve this one... buffer dynamic parts of the scene graph? How do we do this without really complicating the OSG? One of my thoughts was perhaps the graphics context rendering back end could create it's own own objects to cache the data locally, rather than read from the the scene graph in the draw thread. Such caching of graphics objects could possibly be done by attaching this rendering API specific objects to the scene graph objects, and then updating these cached objects when the scene graph objects are updated. This approach is a bit similar to the factory approach, but pushes the factory into the rendering backend rather than the scene graph interface. There will be other approaches as well.. Need to spend more time pontificating about it... Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
