Hi,
I revisited my osgText performance issue by measuring the time for
copying text.
With some 150,000 copies of my VertexNumber class inheriting from
osgText::Text, I ended up with roughly the following figures using OSG
3.5.6, compared to my previous solution using OSG 3.2.1, calling the
osgText::TextBase copy constructor from my copy constructor (skipping
over osgText::Text copy constructor) and copying the
_textureGlyphQuadMap instead of calling the slower
computeGlyphRepresentation.
3.2.1 without the "trick" above:
40 - 70% slower compared to 3.2.1 with trick
3.5.6 (obviously without the trick):
50 - 90% slower compared to 3.2.1 with trick
10 - 30% slower compared to plain 3.2.1 without trick
Furthermore, in 3.5.6 my application requires about 37% more RAM with
this number of texts, compared to 3.2.1 (both with and without the
trick), but only about 4% more without the texts created.
I'm creating and caching new text instances per vertex number in the
model. Since there are mostly triangles, I'm getting 0,1,2 but also
occasional other numbers up to 7 for special polygons. For a situation
like this, with a large number of texts from a small number of cached
originals, what would be the recommended approach? Maybe osgText isn't
suitable at all?
Regards,
Andreas
On 2017-08-18 11:38, Robert Osfield wrote:
Hi Andreas,
In my rewrite of osgText my approach was that the internal
implementation details aren't meant to be something that users need to
meddle with.
The fact that you are needing to meddle with the internal details to
workaorund performance issues in your usage case suggest an issue with
basic performance/flexibility, The new implementation might change
this performance/flexibility side so perhaps your local changes might
not be needed.
If the new osgText doesn't provide the performance you need for your
usage case perhaps it could be optimized to handle them. Creating an
example that illustrates the usage case which highlights the issues
would be a good first step if you feel this approach has promise.
Finally, I'm open to small tweaks to the API allow easier subclassing.
However, this isn't my preferred approach as any changes to the
internals later would then break end user code that relies upon it -
exactly the problem you are facing now...
Robert.
On 18 August 2017 at 09:14, Andreas Ekstrand
<[email protected]
<mailto:[email protected]>> wrote:
Hi,
With OSG 3.2.1 I have been able to do fast shallow cloning of
osgText::Text in my own subclass, copying the _textureGlyphQuadMap
instead of calling computeGlyphRepresentation, since the latter is
a slow operation for my thousands of texts.
In OSG 3.5.6 this isn't possible, I guess due to a private
GlyphQuads::operator=. So I'm looping through _textureGlyphQuadMap
in my copy constructor and copy its glyphs and primitives
separately instead. But I can't see my copied text at all! If I
save it out to an .osg or .osgt file it's visible in osgviewer.
I guess setting GlyphQuads::operator= private was deliberate, so
can someone explain how I can accomplish fast text cloning in OSG
3.5.6 or optimize it somehow?
Regards,
Andreas
_______________________________________________
osg-users mailing list
[email protected]
<mailto:[email protected]>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
<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
