RE: glDeleteHandle of pfTextures

New Message Reply Date view Thread view Subject view Author view

From: christopher.g.dorosky++at++lmco.com
Date: 04/06/2000 07:00:44


I don't understand.

Does this mean that it is necessary to redo the geostates(that reference
that texture) or not? This could be a horrendous performance hit.
If not, how will the texture know where to go?

I got the idea from this earlier reply.
"You reuse the handle for a different sized texture, or call The
pfTexture::deleteGLHandle does the right thing and calls
glDeleteTextures. Just deleting a texture should recirculate its handle."

Should I call glDeleteTextures instead? Or should I just call
pfDelete(pfTexture) and handle the pain of redoing the geostates?

If this is a sloppy approach, does performer provide a clean approach?

Chris

Christopher Dorosky
Senior Electronic Systems Engineer - Real Time Simulation
Lockheed Martin Missiles and Fire Control - Dallas
christopher.g.dorosky++at++lmco.com
972-603-2349

> ----------
> From: Angus Dorbie[SMTP:dorbie++at++sgi.com]
> Sent: Wednesday, April 05, 2000 6:41 PM
> To: christopher.g.dorosky++at++lmco.com
> Cc: info-performer++at++sgi.com
> Subject: Re: glDeleteHandle of pfTextures
>
> If you just delete the pfTexture then the handle will be recirculated
> internally and ultimately be used with a different image size but that's
> a slightly sloppy approach.
>
> What you are asking for is to delete the gl handle under the pfTexture
> and then when you later reuse the texture you'll be in good shape and
> that's not the case.
>
> Cheers,ANgus.
>
> christopher.g.dorosky++at++lmco.com wrote:
> >
> > It seems the only way to remove something from TRAM is with the
> > glDeleteHandle.
> >
> > So if I have a building that I want paged in and out (because there are
> > many), I can glDeleteHandle when I want it out.
> > However, if this screws up the pfTexture, then it is neccessary to redo
> the
> > geostate that referenced the texture, which is no fun.
> >
> > I assumed that some texformat calls and a pfTexture->format would be
> enough.
> > (to get another glHandle)
> >
> > Is it really this hard just to remove something from texture memory?
> >
> > Christopher Dorosky
> > Senior Electronic Systems Engineer - Real Time Simulation
> > Lockheed Martin Missiles and Fire Control - Dallas
> > christopher.g.dorosky++at++lmco.com
> > 972-603-2349
> >
> > > ----------
> > > From: Angus Dorbie[SMTP:dorbie++at++sgi.com]
> > > Sent: Wednesday, April 05, 2000 4:34 PM
> > > To: christopher.g.dorosky++at++lmco.com
> > > Cc: info-performer++at++sgi.com
> > > Subject: Re: glDeleteHandle of pfTextures
> > >
> > > christopher.g.dorosky++at++lmco.com wrote:
> > > >
> > > > I didn't want to delete the pfTexture. That's not necessary to
> remove it
> > > > from TRAM, is it? That's what I was hoping glDeleteHandle would do.
> > >
> > > But subsequently the pfTexture has no glHandle. I haven't chacked to
> see
> > > what would happen but it seems troublesome. You might bind the old
> name
> > > which will be reused or invalid. Maybe it get's another.
> > >
> > > >
> > > > Is it safe to do pfDeletes in the draw? (I know you usually don't do
> > > this
> > > > for performance reasons)
> > >
> > > No, it's not safe.
> > >
> > > >
> > > > Christopher Dorosky
> > > > Senior Electronic Systems Engineer - Real Time Simulation
> > > > Lockheed Martin Missiles and Fire Control - Dallas
> > > > christopher.g.dorosky++at++lmco.com
> > > > 972-603-2349
> > > >
> > > > > ----------
> > > > > From: Angus Dorbie[SMTP:dorbie++at++sgi.com]
> > > > > Sent: Wednesday, April 05, 2000 4:06 PM
> > > > > To: christopher.g.dorosky++at++lmco.com
> > > > > Cc: info-performer++at++sgi.com
> > > > > Subject: Re: glDeleteHandle of pfTextures
> > > > >
> > > > > christopher.g.dorosky++at++lmco.com wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I have two questions regarding this procedure.
> > > > > >
> > > > > > 1) On a multipipe system, does the glDeleteHandle need to be
> done on
> > > all
> > > > > > pipes (for a shared texture)
> > > > >
> > > > > Yes, in the draw process. You must also defer the deletion of the
> > > > > pfTexture in the app until you have deleted the handles to be
> safe.
> > > > >
> > > > >
> > > > >
> > > > > > 2) Do mipmapped textures require anything more than a
> glDeleteHandle
> > > of
> > > > > the
> > > > > > base texture? ie do you need to get each level and delete it?
> > > > >
> > > > > No.
> > > > >
> > > > > Cheers,ANgus.
> > > > >
> > > > > --
> > > > > For Performer+OpenGL tutorials http://www.dorbie.com/
> > > > >
> > > > > "In the middle of difficulty lies opportunity."
> > > > > --Albert Einstein
> > > > >
> > > >
> -----------------------------------------------------------------------
> > > > List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> > > > Submissions: info-performer++at++sgi.com
> > > > Admin. requests: info-performer-request++at++sgi.com
> > >
> > > --
> > > For Performer+OpenGL tutorials http://www.dorbie.com/
> > >
> > > "In the middle of difficulty lies opportunity."
> > > --Albert Einstein
> > >
> -----------------------------------------------------------------------
> > > List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> > > Submissions: info-performer++at++sgi.com
> > > Admin. requests: info-performer-request++at++sgi.com
> > >
> > -----------------------------------------------------------------------
> > List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> > Submissions: info-performer++at++sgi.com
> > Admin. requests: info-performer-request++at++sgi.com
>
> --
> For Performer+OpenGL tutorials http://www.dorbie.com/
>
> "In the middle of difficulty lies opportunity."
> --Albert Einstein
> -----------------------------------------------------------------------
> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
>


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Thu Apr 06 2000 - 07:03:10 PDT

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