[osg-users] CompositeViewer context cleanup and missing textures

[J.P. Delport]

Hi Robert,

J.P. Delport wrote:
> 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.

Latest svn also works, so you've already fixed what I tried to describe 
above. That'll teach me to update before I go bug hunting.

rgds
jp

> 
> 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.