[osg-users] Custom code in OSG core

Robert Osfield robert.osfield at gmail.com
Thu Nov 26 07:47:28 PST 2009


Hi J-S,

On Thu, Nov 26, 2009 at 2:09 PM, Jean-Sébastien Guay
<jean-sebastien.guay at cm-labs.com> wrote:
> An additional benefit would be when doing runtime creation/destruction of
> contexts. Right now, if you do that, you need to turn off
> unrefImageAfterApply, or else in the new contexts the textures will be
> missing. But this completely removes the benefit of unrefImageAfterApply of
> course, so you have duplicate image data on the CPU memory and GPU memory
> even if you never (or seldom) create new contexts.

The issue of the incompatibility of UnrefImageAfterApply with creating
a series of graphics contexts can to mind yesterday as I was working
on the texture/buffer object pools - what would be useful would be to
be able suppress this feature via a osg::State setting, so that even
if the scene graphs asks for image to be unref'd the osg::State
setting overrides this and prevents it.   I have already implemented a
similar check for when the texture pools are enabled, as you can't mix
UnrefImageAfterApply with texture pools so it's only a small step
beyond.

Another possibility, albeit more radical, would be to get rid of
UnrefImageAfterApply completely and just rely on texture pools
completely for managing memory... ;-)

This doesn't take away form the usefulness of a proxy image capability.

Robert.


More information about the osg-users mailing list