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;) > 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;) best Lars > >> Does OpenSG 2.0 cope with these issues in a different way? > > MFields in 2.0 use the same underlying storage until a modification is > made on one aspect, in which case the aspect gets its own copy of the data. > > Cheers, > Carsten > > ------------------------------------------------------------------------------ > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > _______________________________________________ > Opensg-users mailing list > Opensg-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/opensg-users > ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
