Re: Removing FLT files properly

New Message Reply Date view Thread view Subject view Author view

Marcus Barnes (marcus++at++multigen.com)
Thu, 22 Feb 1996 17:30:12 -0800

On Feb 21, 10:52am, Jason Buksh wrote:
> Subject: Removing FLT files properly
> In the name of efficiency,
>
> Hi,
> I'm loading a FLT file into performer (1.2)
> and attaching it to a pfNode. After I have finished
> using it I pfRemove and then successfully pfDelete
> the object from the hierarchy (TRUE is returned).
> Although the object has been removed I'm not
> actually certain that the memory has been deallocated
> properly (gr_osview -a doesn't change). My question
> is simple :- Does it de-allocate all memory associated
> with the FLT file (Including all textures and materials)
> and if not is it possible ?
>
> J.BUKSH
> VR SOLUTIONS
> University of Salford
> Manchester
> M5 4PP
>-- End of excerpt from Jason Buksh

The short answer is "NO".

The OpenFlight loader (for one) has historically called pfRef() on all
prObject's that it creates. This insures that state resource sharing between
files won't dump core; i.e. the loader owns the shared resources. So things
like pfTexture's and pfGeoState's won't be deleted unless you also pfUnref()
those objects. But then the loader will have pointers to free memory in its
material palette etc. etc. ...

With the advent of Performer 2.0 database paging, this policy may have to
change in the future. Does the application always want pfObject's deleted when
a piece of scenegraph goes away? That would make it impossible for a
builder/loader to share state resources between files. Is an "unref-delete"
traversal needed? i.e. you'd like to be able to call pfUnrefDelete( node ) and
get equivalent traversal semantics as pfDelete().

BTW: In 2.0 pfdBuilder doesn't call pfRef() on its objects but pfdShare() does.

Also, in Performer 1.2, there are many forms of memory leaks such that pfDelete
on a pfNode fails to completely free up memory anyways, regardless of the
reference count.

Regards.

--
    __  ___      ____  _ ______          Marcus Barnes, Member Tech. Staff
   /  |/  /_  __/ / /_( ) ____/__  ____  MultiGen Inc, 550 S. Winchester
  / /|_/ / / / / / __/ / / __/ _ \/ __ \ Blvd. STE 500, San Jose CA 95128
 / /  / / /_/ / / / / / /_/ /  __/ / / / PH:1-408-556-2654 FX:1-408-261-4102
/_/  /_/\__,_/_/\_\/_/\____/\___/_/ /_/  EMAIL: marcus++at++multigen.com

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:52:26 PDT

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