Hi Uwe, Submissions via osg-user run the risk of being missing, the right place to submit is via osg-submissions.
In this instance I've reviewed your changes but have held back from merging as I want to establish exactly what parts are breaking before see changes applied. I also note that your Font.cpp is rather out of date relative to the one in SVN. Robert. On 8/27/07, Uwe Woessner <[EMAIL PROTECTED]> wrote: > Hello Robert > > you might try out the modification to font.cpp which I submitted a while > ago to this list. (see attachment font.zip) > The node you are modifying might not be rendered but the font it uses > is modified during rendering of other text nodes which use the same font. > I added a scope lock to addGlyph. The file might have changed since then > so only copy the scope lock. > addGlyph is only called when characters are rendered for the first time > so it should not be too much of a performance issue, right? > > Uwe > > Osfield wrote: > > Hi Robert, > > > > On 8/27/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > >> We are trying to port an osg 1.2 app to 2.0, and we > >> frequently get crashes when one thread (which is > >> building an osg scene that is not yet being rendered) > >> tries to access fonts while the rendering thread is > >> rendering text. > > > > Another user recently reported problems with loading text in a > > background thread, which fits your problem too. This was recently and > > with the SVN version of the OSG so it looks like the problem persists. > > > > I suspect the problem is either in src/osgText/Font.cpp or the > > freetype plugin, or freetype itself. If we can pinpoint where the > > problem it should be easy to fix - something like adding a mutex to > > serialize the freetype API access. > > > > I don't have an app that recreates this problem with rather limits my > > ability to reproduce and fix it. So I either need an example that > > reproduces the problem or for others to dig into the relevant code and > > fix it. > > > >> Also, on a possibly related note, what happened to > >> "viewer.sync()" in osg 2.0? There doesn't seem to be > >> anything to replace it. Is it no longer necessary? > > > > viewer.sync() is no longer required. The sync is effectively done > > inside the Viewer::renderingTraversals() method which is dispatched by > > Viewer:frame(). The updateTraversal() is also could from within > > frame() as well so one needn't call this either unless you want to > > replace frame() call by it consitient parts. > > > > Robert. > > _______________________________________________ > > osg-users mailing list > > [email protected] > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > > -- > > \\\|/// *HLRS, High Performance Computing Center Stuttgart* > _I_ ( o o ) *Visualization/VR* _I_ > ([EMAIL > PROTECTED])--oo0O--(_)--O0oo------------------------------------------([EMAIL > PROTECTED]) > | | Uwe Woessner [EMAIL PROTECTED] | | > | | .ooo0 http://www.hlrs.de/people/woessner/ | | > |_| ( ) Oooo. Phone: +49-711-6856-5790 or ...-5970 |_| > ([EMAIL PROTECTED])-------\ (---( > )-----------------------------------------([EMAIL PROTECTED]) > I \_) ) / I > (_/ > > _______________________________________________ > 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
