[osg-users] Speeding Up osgText?

Nick Bryan nick at streetlife.co.uk
Fri Sep 5 14:53:10 PDT 2008


Hi Ryan,
can't answer your question immediately but i am embarking on a lot of 
work around osgText so thanks for the heads up and the detailed post.  
I'll consider your points as i work through what i need to do.  Will 
obviously post feedback to the group.

rgds
Nick

Kawicki, Ryan H wrote:
> This is in reference to a previous question that has been posed.  Sorry
> if this has already been addressed.
>
> http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2
> 008-April/009652.html
>
> Our application seems to be hitting this same issue.  We are trying to
> render quite a bit of text on the screen, and we seem to be getting
> burned by both the setText( ... ) and the drawImplementation.
>
> We are currently using an older version of OSG, but we are planning on
> moving to 2.6.0 relatively soon.  I have looked at our current version
> of osgText and the 2.6.0 version and can conclude that this will still
> be an issue.
>
> Our application is building the text shapes with SCREEN_COORDS for the
> character size mode and SCREEN for axis alignment.
>
> What I have noticed is that for each text shape update, the function
> computeGlyphRepresentation is called to recompute the glyph information.
> This function then calls the function computePositions.  Here is what
> compute positions looks like.
>
> void Text::computePositions()
> {
>     unsigned int size =
> osg::maximum(osg::DisplaySettings::instance()->getMaxNumberOfGraphicsCon
> texts(),_autoTransformCache.size());
>     
>     // FIXME: OPTIMIZE: This would be one of the ideal locations to
>     // call computeAverageGlypthWidthAndHeight(). It is out of the
> contextID loop
>     // so the value would be computed fewer times. But the code will
> need changes
>     // to get the value down to the locations it is needed. (Either pass
> through parameters
>     // or member variables, but we would need a system to know if the
> values are stale.)
>
>     for(unsigned int i=0;i<size;++i)
>     {
>          computePositions(i);
>     }
> }
>
> As can be seen by the first line, the maximum size is being obtained
> from the maximum number of graphics contexts or the size of
> _autoTransformCache.  For me this is set to 32, since the default was
> never being changed.  The computePositions function is a very expensive
> operation, and a minor flaw in our design was causing a huge impact in
> performance.  It might be a good idea to either assert on or to check
> the traversalNumber from the _autoTransformCache to make sure the
> context is a valid one.
>
> Performance is still down for our application.  I think some of the
> problem is related to this computePositions function still.  Our
> application is frequently setting text, so we incur a CPU hit to
> recalculate all the glyph vertices.  When the text is visible, we incur
> the same CPU hit to recalculate all the glyph vertices since the
> _autoTransformCache model view matrix are always different between the
> update of the text and the current state of the draw phase.  Here's the
> draw implementation for text.
>
> void Text::drawImplementation(osg::State& state) const
> {
>     unsigned int contextID = state.getContextID();
>
>     < CODE REMOVED >
>
>     if (_characterSizeMode!=OBJECT_COORDS || _autoRotateToScreen)
>     {
>         < CODE REMOVED >
>
>         AutoTransformCache& atc = _autoTransformCache[contextID];
>         const osg::Matrix& modelview = state.getModelViewMatrix();
>         const osg::Matrix& projection = state.getProjectionMatrix();
>
>         < CODE REMOVED >
>
>         bool doUpdate = atc._traversalNumber==-1;
>         if (atc._traversalNumber>=0)
>         {
>             if (atc._modelview!=modelview)
>             {
>                 doUpdate = true;
>             }
>             else if (width!=atc._width || height!=atc._height)
>             {
>                 doUpdate = true;
>             }
>             else if (atc._projection!=projection)
>             {
>                 doUpdate = true;
>             }
>         }
>         
>         atc._traversalNumber = frameNumber;
>         atc._width = width;
>         atc._height = height;
>         
>         if (doUpdate)
>         {    
>             atc._transformedPosition = newTransformedPosition;
>             atc._projection = projection;
>             atc._modelview = modelview;
>
>             computePositions(contextID);
>         }
>         
>     }
>
>     < CODE REMOVED >
> }
>
> With the draw implementation above and the setText all being called
> within a render frame, we are computing the glyph vertices twice.  I
> think we can speed things up a bit, but I need some information.
>
> Is there a reason as to why we need to call computePositions from within
> computeGlyphRepresentation if the drawImplementation will already take
> care of that?  As far as I can see, computeGlyphRepresentation is
> already doing the calculations for the bounding box.  Makes sense that
> we only have that information.  We can then just allow the
> drawImplementation do the nasty work of recalculating the vertices by
> calling computePositions.
>
> Does anyone have any suggestions that might help in improving
> performance?  I am wondering if some of this work could be moved from
> the CPU and pushed to the GPU.
>
> Sorry for the long post and thanks for any suggestions.
>
> Ryan H. Kawicki
> The Boeing Company
> Training Systems & Services
> Software Engineer
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>   



More information about the osg-users mailing list