[osg-users] CompositeViewer context cleanup and missing textures

J.P. Delport jpdelport at csir.co.za
Tue Nov 24 06:38:37 PST 2009


Hi Robert,

it seems to be something broken on context destruction with the new 
texture pool. The orphaned list does not seem to be cleared properly. A 
texture is used from the orphaned list even though the context it 
belonged to had been destroyed earlier.

When libosg is compiled with

#define USE_NEW_TEXTURE_POOL 1

commented out, the example works as expected.

regards
jp

J.P. Delport wrote:
> Hi,
> 
> Robert Osfield wrote:
>> Hi J.P.
>>
>> I'm still knee deep in merging submissions so can't yet go off
>> reviewing user code.  In principle it is possible to mange open and
>> closing viewers.  I can point you in the right direction but have to
>> let you get on with it otherwise.
> 
> I understand, I'll try search for cleanup code, just not sure where to 
> start.
> 
> Anyone else?
> 
> jp
> 
>>
>> Robert.
>>
>> On Tue, Nov 24, 2009 at 12:32 PM, J.P. Delport <jpdelport at csir.co.za> 
>> wrote:
>>> Hi Robert,
>>>
>>> Robert Osfield wrote:
>>>> Hi J.P,
>>>>
>>>> The typical problem is that the scene graph has been set up to unref
>>>> texture images after apply so when it comes to reloading the texture
>>>> images there aren't the to download.
>>> should this still happen when I'm completely reloading a scene after the
>>> viewer and scene have been deleted completely?
>>>
>>> It seems that OSG thinks there is still a valid texture it can use after
>>> I've deleted the scene and CompositeViewer.
>>>
>>> Running the attached e.g.:
>>> ./test cow.osg
>>>
>>> Constructing PixelBufferObject for image=0x9547928
>>> _maxTexturePoolSize=0
>>> _maxBufferObjectPoolSize=0
>>> Created new TextureObject, _numOfTextureObjects 1
>>> Created new TextureObject, _numOfTextureObjects 1
>>>
>>> now I click the X on the window and the app deletes the scene and 
>>> viewer and
>>> creates them anew:
>>>
>>> _maxTexturePoolSize=0
>>> _maxBufferObjectPoolSize=0
>>> Reusing orhpahned TextureObject, _numOfTextureObjects=1
>>> Warning: detected OpenGL error 'invalid value' after RenderBin::draw(,)
>>> Reusing orhpahned TextureObject, _numOfTextureObjects=1
>>> Warning: detected OpenGL error 'invalid value' after RenderBin::draw(,)
>>>
>>> So it tries to reuse something that's not there? How can I convince 
>>> OSG to
>>> drop all caches/buffers/GL objects?
>>>
>>> jp
>>>
>>>
>>>> Robert.
>>>>
>>>> On Tue, Nov 24, 2009 at 9:17 AM, J.P. Delport <jpdelport at csir.co.za>
>>>> wrote:
>>>>> Hi all,
>>>>>
>>>>> I've run into the classic "missing textures" problem when stopping and
>>>>> restarting a compositeviewer multiple times in the same app. From
>>>>> previous
>>>>> threads on this problem it seems to be context cleanup/GL object 
>>>>> cleanup
>>>>> that does not get done properly, but I'm just using the normal
>>>>> CompositeViewer and not messing with contexts/windows/sceneviews 
>>>>> myself,
>>>>> so
>>>>> I thought the cleanup would be handled correctly.
>>>>>
>>>>> Attached a very slightly modified compositeviewer example. All it 
>>>>> does is
>>>>> create/destruct the compositeviewer 5 times. When the viewer is 
>>>>> created
>>>>> for
>>>>> the second time, all my textures are gone (just run without any
>>>>> arguments).
>>>>>
>>>>> Can anyone confirm the missing textures? Any hints as to what else 
>>>>> needs
>>>>> to
>>>>> be done to make sure everything is cleared/flushed correctly?
>>>>>
>>>>> thanks
>>>>> jp
>>>>>
>>>>> -- 
>>>>> This message is subject to the CSIR's copyright terms and conditions,
>>>>> e-mail
>>>>> legal notice, and implemented Open Document Format (ODF) standard. The
>>>>> full
>>>>> disclaimer details can be found at 
>>>>> http://www.csir.co.za/disclaimer.html.
>>>>>
>>>>> This message has been scanned for viruses and dangerous content by
>>>>> MailScanner, and is believed to be clean.  MailScanner thanks Transtec
>>>>> Computers for their support.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> osg-users mailing list
>>>>> osg-users at lists.openscenegraph.org
>>>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org 
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> osg-users mailing list
>>>> osg-users at lists.openscenegraph.org
>>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org 
>>>>
>>>>
>>> -- 
>>> This message is subject to the CSIR's copyright terms and conditions, 
>>> e-mail
>>> legal notice, and implemented Open Document Format (ODF) standard. 
>>> The full
>>> disclaimer details can be found at 
>>> http://www.csir.co.za/disclaimer.html.
>>>
>>> This message has been scanned for viruses and dangerous content by
>>> MailScanner, and is believed to be clean.  MailScanner thanks Transtec
>>> Computers for their support.
>>>
>>>
>>> _______________________________________________
>>> osg-users mailing list
>>> osg-users at lists.openscenegraph.org
>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org 
>>>
>>>
>>>
>> _______________________________________________
>> osg-users mailing list
>> osg-users at lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> 

-- 
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.  MailScanner thanks Transtec Computers for their support.



More information about the osg-users mailing list