Hi Robert Another solution is to introduce VertexArrayObject in OSG, then glVertexAttrib*Pointer will be call once, and we just need to bind VAO next time.
VAO and glVertexAttribIPointer are in OpenGL core since version 3.0 so either we use both if implementation allow it or we use anyone. David 2013/5/30 Robert Osfield <[email protected]> > Hi David, > > On 30 May 2013 13:54, David Callu <[email protected]> wrote: > > The best way i know to remove if/switch or other control flow keyword, is > > virtual function > > so my first idea was to add functor in ArrayData like this > > > > struct OSG_EXPORT ArrayData > > { > > struct ApplyOperatorABC > > { > > ApplyOperator(ArrayData & data) : _data(data) {} > > virtual void operator() (osg::State & state, unsigned int > > index) = 0; > > > > ArrayData & _data; > > }; > > > > struct ApplyFloatOperator : public ApplyOperatorABC > > { > > ApplyFloatOperator(ArrayData & data) : > ApplyOperator(data) > > {} > > > > virtual void operator() (osg::State & state, unsigned int > > index) > > { state.setVertexAttribPointer( index, _data.array, > > _data.normalize ); } > > }; > > > > struct ApplyIntOperator : public ApplyOperatorABC > > { > > ApplyIntOperator(ArrayData & data) : ApplyOperator(data) > {} > > > > virtual void operator() (osg::State & state, unsigned int > > index) > > { state.setVertexAttribIPointer( index, _data.array ); } > > }; > > > > struct ApplyDoubleOperator : public ApplyOperatorABC > > { > > ApplyDoubleOperator(ArrayData & data) : > ApplyOperator(data) > > {} > > > > virtual void operator() (osg::State & state, unsigned int > > index) > > { state.setVertexAttribLPointer( index, _data.array ); } > > }; > > > > .... > > .... > > .... > > ApplyOperatorABC * _applyOperator; > > }; > > > A function would require a pointer reference to the functor object, > then a virtual function call so would avoid an if' statement but is > unlikely to help overall. > > > Well, we introduce a new feature provide by OpenGL and not yet provided > by > > OSG. > > The cost is an extra CPU overhead > > Smart programming avoids overheads when you introduce new features. > Most of the OSG enables adding features without impacting on the > performance of code that doesn't require that feature. > > Adding a performance overhead on everyone for a capability required by > the few is something we have to think very hard about doing. If we > want to merge such changes they really have to justify themselves and > work to minimize and ideally avoid overheads completely. Right now I > don't believe we have a solution that has low enough cost. > > Robert. > _______________________________________________ > osg-submissions mailing list > [email protected] > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org >
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
