Hi James, I've now reviewed your changes and they an improvement over the old code, still not perfect but certainly better. I'm not 100% happy with not hiding the local object cache as was attempted in the previous code - this swap code existed for a reason, if it was buggy. Still I believe your code will be more reliable and not have the same thread issues that original code had so I'll check it in and let us see how things pan out.
Cheers, Robert. On Tue, Mar 24, 2009 at 4:28 AM, James Killian <[email protected]>wrote: > > Ok here is something that should work. This was built with 9943 (since I > couldn't use 9944). > I've tested with our game and now the cache is properly populating once > again. :) > > > James Killian > > ----- Original Message ----- > *From:* Robert Osfield <[email protected]> > *To:* OpenSceneGraph Submissions<[email protected]> > *Sent:* Monday, March 23, 2009 9:07 AM > *Subject:* Re: [osg-submissions] Text3D fix > > Hi James, > > You are welcome to dive and look a full solution. Exactly what this might > look like I can't say right now, my hunch is that we'll need to refactor the > cache management such as making it state of ReaderWriter::Options object. > If you don't feel comfortable with having a bash then you'll need to wait > for me to have a free slot in which to tackle it. > > Robert. > > On Mon, Mar 23, 2009 at 1:58 PM, James Killian > <[email protected]>wrote: > >> >> Robert, >> Is there enough information in the previous email to know what direction I >> wanted to address this issue? >> >> If you want I can make the fixes and submit it... Ideally I'd like to know >> if this sounds like it should work or if you wanted to pursue managing the >> cache differently (i.e. attached to the ReaderWriter::Options object). >> >> Please let me know when you have a chance... Thanks. >> >> >> ----- Original Message ----- >> From: "James Killian" <[email protected]> >> To: "OpenSceneGraph Submissions" < >> [email protected]> >> Sent: Thursday, March 19, 2009 1:44 PM >> Subject: Re: [osg-submissions] Text3D fix >> >> >> > Is the read implementation's useObjectCache = false suppose to override >> all >> > cache hints that were provided by the options? I'm assuming not but >> just >> > the cache hint of that type... if so... >> > >> > Seems like instead of passing a bool we could be passing the >> > CacheHintOptions type and do an if with that against the >> readFunctor.options >> > something like: >> > >> > readImplementation (readFunctor, CacheHintType) >> > { >> > bool useObjectCache= readfunctor._options->getObjectCacheHint() & >> > CacheHintType; >> > if (useObjectCache) >> > { >> > } >> > else >> > { >> > read(); >> > } >> > } >> > >> > That should be thread safe since everything is protected within the >> > parameters >> > What do you think? >> > >> > On a side note it appears all the derived functor types construct the >> bool >> > using cachehints & the type they represent. >> > >> > >> > ----- Original Message ----- >> > From: "Robert Osfield" <[email protected]> >> > To: "OpenSceneGraph Submissions" >> <[email protected]> >> > Sent: Thursday, March 19, 2009 11:34 AM >> > Subject: Re: [osg-submissions] Text3D fix >> > >> > >> > > Hi James, >> > > >> > > The swaps are in their to prevent the local object cache from being >> > > populated for the case when useObjectCache is false. >> > > >> > > Reviewing the code now it's clear that the code isn't robust in the >> > presence >> > > of multi-threading. Removing the local cache and the swaps wouldn't >> solve >> > > anything as it would simple may that the cache is used even when >> you've >> > > asked for it not to be used. >> > > >> > > As to solution it's not going to be straight forward, it'll require >> the >> > > cache to be managed differently, and most likely attached to the >> > > ReaderWriter::Options object. >> > > >> > > Robert. >> > > >> > > On Thu, Mar 19, 2009 at 2:38 PM, James Killian >> > <[email protected]>wrote: >> > > >> > > > > Behaviours: >> > > > > Cache management is delegate to osgDB::Registry, but cache >> > > > > coherence (load a file with option then reuse it, deactivate >> the >> > > > > cache when load a specific file or don't cached the loaded >> file) >> > > > > is user's responsibility. >> > > > >> > > > I actually ran into a similar issue... let me explain here: >> > > > >> > > > Looking at the latest rev 9884 of Registry.cpp around line 1641 in >> the >> > > > readImplementation() we see >> > > > else >> > > > { >> > > > ObjectCache tmpObjectCache >> > > > swap >> > > > read >> > > > swap >> > > > return >> > > > } >> > > > >> > > > I would dare to submit to remove the swaps, but first ask if they >> were >> > > > removed what would be broken as this has been this way for a long >> time. >> > > > >> > > > Stress that breaks _objectCache: >> > > > As of now if I have 2 threads loading where some object types are >> cached >> > > > and >> > > > others are not (e.g. cached images but not nodes)... what happens is >> > that >> > > > the line 1631 addEntry() adds to the tmpOjectCache, and therefore >> the >> > real >> > > > _objectCache never gets populated. :( >> > > > >> > > > If someone can at least explain why the swaps were added I would be >> > > > eternally grateful. >> > > > >> > > > >> > > > >> > > > ----- Original Message ----- >> > > > From: "David Callu" <[email protected]> >> > > > To: "OpenSceneGraph Submissions" >> > <[email protected] >> > > > > >> > > > Sent: Friday, February 27, 2009 8:47 AM >> > > > Subject: [osg-submissions] Text3D fix >> > > > >> > > > >> > > > > Hi Robert >> > > > > >> > > > > Problem: >> > > > > osgText::Text and osgText::Text3D use the same font file. >> > > > > The first really load the file and obtain an osgText::Font >> > object, >> > > > > the second use the cache created during the first load of the >> > > > > font file, and so obtain an osgText::Font object instead of >> > > > > osgText::Font3D object. To obtain an osgText::Font3D object, >> > > > > osgText::Text3D call osgDB::readObjectFile(...) with an >> option >> > > > > to specify the plugin we want an osgText::Font3D instead of >> > > > > osgText::Font. >> > > > > >> > > > > Generalised Problem: >> > > > > In osgDB::Registry, loaded file cache is referenced by the >> name >> > > > > of this file, so if I load a file with some options, and the >> cache >> > > > > already contain object for this filename, I obtain an object >> > > > > potentially not loaded with my options. >> > > > > >> > > > > Behaviours: >> > > > > Cache management is delegate to osgDB::Registry, but cache >> > > > > coherence (load a file with option then reuse it, deactivate >> the >> > > > > cache when load a specific file or don't cached the loaded >> file) >> > > > > is user's responsibility. >> > > > > >> > > > > Text3D solution: >> > > > > Postfix the font file name by .text3d or something similar and >> > then >> > > > have >> > > > > the freetype plugin return >> > > > > osgText::Font3D when it detects this. >> > > > > This operation is done by osgText::readFont3DFile() which >> unsure >> > the >> > > > > filename have .text3d as extension. >> > > > > This is totaly transparent for user, and backward compatible. >> > > > > >> > > > > >> > > > > BTW, I fix the bug about the Normal of 3D text. Currently, the >> front >> > and >> > > > > wall face have >> > > > > the same normal (0,0,1) in the Text3D object coordinate. Now the >> wall >> > > > face >> > > > > have its own >> > > > > normal array computed by the plugin. >> > > > > >> > > > > BTW 2, I implement >> > > > > - void Text3D::accept(osg::Drawable::ConstAttributeFunctor& af) >> const >> > > > > - void Text3D::accept(osg::PrimitiveFunctor& pf) const >> > > > > so now statistics are well reported. >> > > > > >> > > > > I join modified file in osgText3D.tgz and a the original test in >> > > > > testText3D.tgz >> > > > > >> > > > > Cheers >> > > > > David Callu >> > > > > >> > > > >> > > > >> > > > >> > > >> > >> > >> -------------------------------------------------------------------------- >> > -- >> > > > ---- >> > > > >> > > > >> > > > > _______________________________________________ >> > > > > osg-submissions mailing list >> > > > > [email protected] >> > > > > >> > > > >> > > > >> > >> >> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org >> > > > > >> > > > >> > > > _______________________________________________ >> > > > osg-submissions mailing list >> > > > [email protected] >> > > > >> > > > >> > >> >> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org >> > > > >> > > >> > >> > >> > >> -------------------------------------------------------------------------- >> -- >> > ---- >> > >> > >> > > _______________________________________________ >> > > osg-submissions mailing list >> > > [email protected] >> > > >> > >> >> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org >> > > >> > >> > _______________________________________________ >> > osg-submissions mailing list >> > [email protected] >> > >> >> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org >> > >> >> _______________________________________________ >> osg-submissions mailing list >> [email protected] >> >> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org >> > > ------------------------------ > > _______________________________________________ > osg-submissions mailing list > [email protected] > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > > _______________________________________________ > osg-submissions mailing list > [email protected] > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > >
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
