Hi Rafa,
I think Paul merged improvements made to DatabasePager made to
svn/trunk into 2.8.3.
The improvements change the way that PagedLOD's are expired, changing
it from time based expiry to a system where the number of PagedLOD are
capped to a below a users specified maximum, if the number of PagedLOD
is below value then it won't expiry any subgraphs, only when new
subgraphs are loaded and the new number exceeds the max will the pager
start expiring old PagedLOD's. This scheme is far more reliable and
controllable than the old time based scheme.
In your case it could be that the default max value of 500 is too high
for your application, in which case you can adjust it down via the
OSG_MAX_PAGEDLOD env var or programmatically via the DatabasePager
method:
/** Set the target maximum number of PagedLOD to maintain in memory.
* Note, if more than the target number are required for
rendering of a frame then these active PagedLOD are excempt from being
expiried.
* But once the number of active drops back below the target
the inactive PagedLOD will be trimmed back to the target number.*/
void setTargetMaximumNumberOfPageLOD(unsigned int target) {
_targetMaximumNumberOfPageLOD = target; }
If you are still seeing problems then it could be that there is a bug,
and there is chance that it might already be addressed in svn/trunk or
one of the 2.9.x series. I'm actually working of
DatabasePager/IncrementalCompileOperation right now so it's not a bad
time for me to look at a regression if you can provide guidance on how
to reproduce the problem.
Cheers,
Robert.
On Tue, Oct 19, 2010 at 11:52 AM, Rafa Gaitan <rafa.gai...@gmail.com> wrote:
> Hi,
>
> We are currently using osg 2.8.3, with osgVirtualPlanets in a GIS
> application (gvSIG-3D). Trying to get a new build we migrated from
> 2.8.2 to 2.8.3.
>
> Testing the build we have realized that the memory doesn't free as
> "fast" as previous version, getting a big memory usage of the
> application.
>
> Getting deep on the issue we have compared differences between 2.8.2
> an 2.8.3 on DatabasePager and we have seen that some code:
>
> if (osgDB::Registry::instance()->getSharedStateManager())
> osgDB::Registry::instance()->getSharedStateManager()->prune();
>
> // update the Registry object cache.
>
> osgDB::Registry::instance()->updateTimeStampOfObjectsInCacheWithExternalReferences(frameStamp.getReferenceTime());
> osgDB::Registry::instance()->removeExpiredObjectsInCache(expiryTime);
>
> has been removed from the next methods:
>
> void DatabasePager::capped_removeExpiredSubgraphs(const
> osg::FrameStamp& frameStamp)
> void DatabasePager::expiry_removeExpiredSubgraphs(const
> osg::FrameStamp& frameStamp)
>
> I'm not sure if the changes are intentionally or maybe a bug was
> introduced in this part of code.
>
> What do you think?
>
> Thanks!
> Rafa.
>
>
> --
> Rafael Gaitán Linares
> Instituto de Automática e Informática Industrial http://www.ai2.upv.es
> http://gvsig3d.blogspot.com
> Ciudad Politécnica de la Innovación
> Universidad Politécnica de Valencia
> _______________________________________________
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
