Hello, sorry for the rather long delay, got stuck with other not OpenSG related stuff. More answers to pending questions are coming soon.
On Tue, 2012-04-17 at 17:08 +0200, Lars Henning Wendt wrote: > Hi Carsten, > > thanks for the answers so far. > > In the meanwhile a colleague of mine mentioned something to be aware of: > If geo->setPositions(OSG::GeoPositions3f::create()); is called then the > std::vector<FieldContainerPtr> in the FieldContainerFactory, will > increase each time. see: > > http://www.opensg.org/wiki/FAQ#OpenSGseemstoleaksomememorycontinuously > > So even if this may not be a major issue, a solution which circumvent > this problem would be appreciated;) 2.x currently uses a hash map so that will get around the linear increase with every field container. Backporting this to OpenSG 1.8 should not be a problem. > > What field are we talking about here exactly? Geometry::_sfPositions is > > just storing a pointer to a GeoPositionsXX instance and there is always > > as many instances of a FieldContainer as there are aspects. The actual > > position data is stored in GeoPositionsXX::_field which should share > > their storage. > > My initial observation was, that the > GeoPositionsXX::_field::_values::capacity is different in each thread. > Even after syncing. From this I concluded that the data is not shared. > > > Gerrit: Do you know if that works independent of OSG_FIXED_MFIELDSYNC? > > And is that defined by default these days? > > I stumbled over this, and it doesn't seem to be defined by default. But > I have a quite old version (2009/06). > > Would be good to know, if OSG_FIXED_MFIELDSYNC fixes this issue and if > it's default and safe to use by now. Before I'm trying to invest much > time building a current 1.8 version;) hmm, I would have to look into it in detail, that is just to long ago, but if my memory serves me correctly it never really worked perfectly in 1.8 (it sounds like we switched back to copying for whatever reason) and was one of the main motivations to reimplement a lot of the basics from scratch for 2.x. As for the current versions, given that I did not work on OpenSG 1.x in 2009 anymore I would not expect any of the newer versions to address any of the issues. So now comes the unpopular bit, yes, there is a general fix, but this fix is OpenSG 2.x itself. Given this, the amount of time needed, and that I haven't used OpenSG 1.x for a very long time (years), I'm not very enthusiastic to spend time on fixing it for 1.8 as this time would have to be taken of 2.x developments and would just replicate what we went through for 2.x, most likely coming to a very similar result. So in short, I am very reluctant to spend time on it and it would need really really good arguments to convince me otherwise. Sorry for not having a better answer. kind regards gerrit ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
