Hello Lars,
On 04/17/2012 07:12 AM, Lars Henning Wendt wrote:
> I've some question to OSG::Geometry fields (like e.g. positions,
> normals, etc) in OpenSG 1.8. In particular what happens when changing
> their capacity combined with thread synchronization?
>
> The size of such a positions field (and all others) decreases and
> increases during runtime in my application. So I tried the shrink()
> function to get rid of some reserved memory overhead. But this only
> works for the thread from which the function is called, because during
> thread synchronization (applyChangeList()) a simple copy assignment is
> made.
yes, that behaviour essentially comes from the std::vector
implementation, which is the underlying storage for MField.
> The workaround I've found is to create a new GeoPositions3f each time I
> decrease the size of positions.
> Is this an appropriate solution? Which drawbacks does it have?
hmm, can't think of anything too major right now.
> Additionally it seems to me that there are always copies of these fields
> for both aspects. If that's the case it would mean a big overhead. Is
> this true? I thought before that the data is not copied until
> beginEditCP() is called.
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.
Gerrit: Do you know if that works independent of OSG_FIXED_MFIELDSYNC?
And is that defined by default these days?
> 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
