Tom McReynolds (tomcat++at++proxima)
Thu, 8 Feb 1996 16:23:27 -0800
You have to call it in the draw process because that's where the GL state
is. The reason it's a separate function is so you can do some of the
texture formatting overhead early, when you have spare cycles, instead of
having to do it when you need the texture, when the system is more loaded.
If you haven't formatted the texture using pfFormatTex() ahead of time,
the formatting work will be done when pfApplyTex() or pfLoadTex() is called.
Given the above, calling draw in the DBASE process won't do the right thing,
since the setup calls executed won't affect the GL context. But it shouldn't
hang. I guess the simple answer is, "call pfFormatTex() in the DRAW process
and you won't have problems".
One (possibly obvious) suggestion; as you're bringing in new textures, call
pfFormatTex() at the end of the frame, when your hardware is busy rendering
the current scene. That way you can format textures that you've read in, but
aren't needed for this frame, at a time when you have some spare cyles.
-Tom
> Date: Wed, 07 Feb 1996 16:26:40 -0500
> From: Theodore Drapas <TDRAPAS++at++dcscorp.com>
> To: info-performer++at++sgi.sgi.com
> Subject: pfFormatTex
>
> Hi,
> Can anyone tell me if pfFormatTex can be called from the forked DBASE
> process in Performer 2.0 ? I have no problem calling it from the DRAW
> process. When invoked from DBASE it does not return. Do I have to
> make sure I call pfBufferAddChild, pfMergeBuffer after invoking
> pfFormatTex ?
>
> Thanks
> Ted
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:52:23 PDT