Mason D. Menninger (mason++at++praxis.jsc.nasa.gov)
Mon, 26 Apr 1999 14:32:44 -0500 (CDT)
As a follow up....
I usually enjoy "discovering" these things on my own, but I'm in
a bit of a time crunch at the moment. Any suggestions on how
to retrieve the gl texture handles from geometry brought in
with the OpenFlight loader? And better yet, any suggestions on
timing the removal of the texture memory from the draw process
with the removal of the associated node in the paging process?
-Mason
mason++at++praxis.jsc.nasa.gov
> From src++at++rose.engr.sgi.com Fri Apr 23 19:21 CDT 1999
> Date: Fri, 23 Apr 1999 17:21:01 -0700 (PDT)
> From: src++at++rose.engr.sgi.com (Sharon Clay)
> To: Angus Dorbie <dorbie++at++sgi.com>, MLM Veraart <Veraart++at++fel.tno.nl>
> Subject: Re: The infamous dbase paging memory leak
> Cc: "Mason D. Menninger" <mason++at++praxis.jsc.nasa.gov>, info-performer++at++sgi.com
> Mime-Version: 1.0
>
>
> +>---- 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++
>
This archive was generated by hypermail 2.0b2 on Mon Apr 26 1999 - 12:32:51 PDT