"Just to stress out my lock I can start a second thread issuing
display command"
Are you locking OpenGL contexts correctly? Use OpenGL Profiler to
detect if you are doing so, remember you can only have one thread on a
context at a time or you will see this error.
If all looks good this indicates a bug in the driver, file a bug with
a way to reproduce this and the system configuration information.
Thanks
Mike
On Apr 30, 2009, at 1:48 PM, Alexander Repenning wrote:
I know what is causing this kind of problem in general but I have
placed, or so I think, locks in all the right places (e.g., in
drawRect) to avoid these kinds of issues. My app is using a
NSopenGLView with a thread for animation + display. The animation
works as expected and the lock appears to hold up as well. Just to
stress out my lock I can start a second thread issuing display
command. No problem: no locking up and no corruption of the OpenGL
command stream. BUT, if I resize my window I get the "The graphics
driver has detected a corruption in its command stream" console
message and my animation freezes.
I am wondering if a window resize is causing my NSopenGLView to
generate some OpenGL commands other than the ones contained in a
locked section of code doing the drawRect that I am not aware of?
Interestingly, this problem only appears in cases where drawing is
really slow, e.g., if the frame rate drops below 10 FPS. Sounds like
there is some kind of racing condition.
all the best, Alex
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Mac-opengl mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Mac-opengl mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
