The following problem first appeared in 10.3.6:
On a Quicksilver G4 with a GeForce4 MX, I am running code that
repeatedly updates a texture by calling glTexSubimage2d. I'm using
texture range, the GL_STORAGE_CACHED_APPLE storage hint and
GL_UNPACK_CLIENT_STORAGE_APPLE set to GL_TRUE.
All is well until the display goes to sleep at the time specified in
the Energy Saver preference pane. As soon as this happens, every call
to glTexSubImage2d (on the same texture) results in a memory
allocation, which is not freed even after the display is woken up from
sleep. If left sleeping for long enough, the machine runs out of real
memory and panics. Throughout sleep, glGetError keeps returning 0
after the calls to glTexSubImage2D.
OpenGL Driver Monitor shows that as soon as display sleep begins,
textureCount starts increasing steadily (supposedly by a constant
number with each call to glTexSubImage2d). The increase stops when
sleep ends, but there's no decrease back to the original value.
As I said, this behavior is new to 10.3.6, and is driver-dependent (it
doesn't happen for example on the GeForce FX 5200).
Can this behavior be considered normal? (I've already submitted a bug
report). Since glGetError doesn't indicate a problem, is there a
*simple* way for me to tell that I shouldn't be bothering with all the
texturing since the display adapter was shut down? I suppose I could
use CGDirectDisplay(?) or whatever to find my display in the IO
registry, then find its adapter and query its power management
variables, but I'm hoping for something easier.
I'd appreciate any insight into this issue!
-- Dan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Mac-opengl mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/mac-opengl/
email@hidden
This email sent to email@hidden