Hi JS, On Thu, Jan 14, 2010 at 4:06 PM, Jean-Sébastien Guay <[email protected]> wrote: > If we had a ProxyImage as you suggest, then we could keep > unrefImageDataAfterApply turned on, and reclaim the CPU-side memory, and > then when a new window would be opened the images would be reloaded > transparently to be applied to the new context. Taking a bit more time to > open a new window (to reload the images) is not really a big issue in this > case.
I had originally thought that a proxy image would be the solution to this issue, but alas it's only a partial solution as it only handles the case where the imagery is loaded from image files on disk, not for archives such as .ive files that contain images. Most paged databases use .ive's so most databases wouldn't be supportable so we're back to disable the unref after apply. On a slightly different topic, the unrefImageAfterApply is now a bit less critical to enable as we now have the texture object pool that allows us to cap the memory usage on the driver side, so retaining image on the CPU is no longer the overhead that it once was. I have even considered the possibility of removing this unrefImageAfterApply feature completely and instead rely up the texture pool far more. FYI, when the texture pool is enable it requires the unrefImageAfterApply to be disabled so automatically disables it. > So I think there's value in this beyond offline database processing. I hope > you can find a compromise that both Robert and you will be happy with, so > that this work can be integrated. Even without the unrefImageAfterApply issue I believe there is still value in a proxy image scheme. The scheme originally proposed wasn't good for real-time rendering as it would have broken frame any time an image was loaded, so it's only main benefit would have been for handling specific types of large databases during database processing stages rather than rendering. My suggestion of use a node callback had the potential of fixing the runtime issues, but requires more explicit handling of proxy images for the database processing side of things. It's a different trade off in terms of functional strengths. Robert. _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
