[osg-users] Cloning text

[Andreas Ekstrand]

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 
> <andreas.ekstrand at remograph.com 
> <mailto:andreas.ekstrand at remograph.com>> 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
>     osg-users at lists.openscenegraph.org
>     <mailto:osg-users at lists.openscenegraph.org>
>     http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>     <http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org>
>
>
>
>
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20170908/da868a5d/attachment.htm>