On Fri, 2008-09-05 at 22:53 +0100, Nick Bryan wrote: > 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.
I'd be very interested in know what and how and why you're doing this. :) I've been asking about some osgText for months to improve osgWidget, but haven't really made any impressions I don't think (we're all pretty busy, as it were). As such, I have begun (and am almost finished!) writing an OSG NodeKit called osgPango, which uses the Pango library to layout text, create high-quality subpixel fonts renderings, etc. Whether or not anyone else will be interested in it is hard to say, but I intend on using it for my own purpose because I get superb font quality (even shadows and outlines!) and a simplified API. I had originally intended to just hack osgText, but the code is far too complicated for me to grok. :) So I just ended up writing a different NodeKit for it, which will be compaitble with osgWidget for sure (in the form of osgPango::Label and osgPango::Input). I have posted many times about osgText in the past, and if you would like I can recall those links here for you to check out (particularly with regards to quality--see osgfont--and the inability to insure that all quads are "pixel-aligned" and that I can access the extents of each text glyph individually for input...) > 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 > > [email protected] > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
