Re: The infamous dbase paging memory leak

New Message Reply Date view Thread view Subject view Author view

Sharon Clay (src++at++rose.engr.sgi.com)
Fri, 23 Apr 1999 17:21:01 -0700 (PDT)

+>---- On Apr 23, 2:38pm, Angus Dorbie wrote:
> Subject: Re: The infamous dbase paging memory leak
->This still won't do it, it's the gl handles you need to delete from the
->draw process. Just deleting the pfTexture will not free the gl memory.
->
->This is the problem most people run into. I've been told it's not a bug,
->it's a deliberately designed that way because an application may attempt
->to use that handle after a texture is deleted.
->
->I personally think it would be reasonable for Performer to delete this
->handle. It's tricky for an application to delete it otherwise.
->

We didn't design to allow folks to use handles that should
have been deleted. However, the handling of texture has
evolved a lot in Performer and so we try to be careful that
as we evolve, we don't break too many things that might be
ingrained in peoples applications that might be difficult to
fix. Deletion of texture handles will 1) potentially greak apps
that took advantage (however incorrectly) of their non-deletion
previously and 2) will create a (hopefully minor) performance hit
in the draw process that is hard to schedule since it would be done
behind your back.
Ultimately, even if you do the handle delete, it still has to
be in the draw - it is just a scheduling issue here.
FYI, we do reuse Id's when allocating new textures
so this should not be an infinite leak. Hopefully this helps for
feedback.

->Feedback on this design issue would be appreciated.

Agreed.

src.

-- 
-----{-----{---++at++   -----{----{---++at++   -----{----{---++at++   -----{----{---++at++
Sharon Rose Clay - Silicon Graphics, Advanced Systems Dev.
src++at++sgi.com  (650) 933 - 1002  FAX: (650) 933 - 0858  MS 8U-590
-----{-----{---++at++   -----{----{---++at++   -----{----{---++at++   -----{----{---++at++

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Fri Apr 23 1999 - 17:21:38 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.