Hi Brad, I haven't reviewed the submission yet but it does make me nervous that you want a means of bypassing the DatabasePager's standard maximum number of PagedLOD. If your application has the space to maintain more PagedLOD then the appropriate thing would be to up this limit to encompass the maximum number - this would result in more PagedLOD being kept around on average than your suggested scheme.
One thing I have considering is changing the default MaximumNumberOfPagedLOD for different platform targets - so embedded space this number would be kept small but for normal desktop targets allow this figure to go up. Perhaps if we had a scheme for checking available memory on a system we'd be able to compute this automatically. Robert. On Tue, Oct 18, 2011 at 6:06 AM, Christiansen, Brad <[email protected]> wrote: > Hi Robert, > > > > The attached files add the ability to control when a paged child becomes > eligible for expiry based on time and/or elapsed frames. > > > > I found that some of the items that had been paged in were being expired on > the first frame that they were not visible (as the cache was full). This > resulted in excessive paging every time the view was moved. With the > following changes I could only allow children to be expired if they had not > been used for e.g. 30 seconds or 60 frames. > > > > The changes were made against trunk revision 12822. > > > > Cheers, > > > > Brad > > ------------------------------------------------------------------------- > DISCLAIMER: This e-mail transmission and any documents, files and previous > e-mail messages attached to it are private and confidential. They may > contain proprietary or copyright material or information that is subject to > legal professional privilege. They are for the use of the intended recipient > only. Any unauthorised viewing, use, disclosure, copying, alteration, > storage or distribution of, or reliance on, this message is strictly > prohibited. No part may be reproduced, adapted or transmitted without the > written permission of the owner. If you have received this transmission in > error, or are not an authorised recipient, please immediately notify the > sender by return email, delete this message and all copies from your e-mail > system, and destroy any printed copies. Receipt by anyone other than the > intended recipient should not be deemed a waiver of any privilege or > protection. Thales Australia does not warrant or represent that this e-mail > or any documents, files and previous e-mail messages attached are error or > virus free. > ------------------------------------------------------------------------- > _______________________________________________ > 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
