Threads crash on swapbuffer(hdc)

OpenGL OpenGL: Basic Coding
1

I’m moving my GLUT creation to Windows, but when I try using threads it all goes horribly wrong. Specifically it crashes when I call swapbuffer inside the thread.

I wondered if it was cos hdc (global) was being accessed elsewhere so I copied it in my thread set up, then made the old hdc point to NULL (still had the same crash GLIDE3X.DLL acess violation or something).

If I call the rendering function using the timer function it works fine.

If I call swapbuffers on its own with no commands whatsoever it crashes. It drive me crazy.

Help would be much appreciated!

Thanks

2

You are using GLUT to create a window, but you are using the WIN32 function SwapBuffer(hDC) to do buffer swap? Doesn’t that cause problems in and of itself?

Why not use glutSwapBuffers()?

Glossifah

<oops> After rereading your post, you mention you are moving to WIN32. Sorry, I assumed you were still using glutCreateWindow() </oops>

[This message has been edited by Glossifah (edited 12-06-2000).]

3

Dont know if this is your problem but you should know of this issue. OpenGL maintains state in a set of variables. Some of these variables are allocated on the stack not the heap (they are used without calling ‘new’ of ‘malloc’). Each and every thread gets it’s own stack to work with and that stack is private to the thread. If you setup a rendering context in a thread then you had better make dang sure that all OpenGL calls are made from that same thread or your calls will be operating on an invalid OpenGL state. The most popular method of achieving this is to set up a ‘rendering thread’ which responds to ‘messages’ from other threads. That is, the other threads do not actually call OpenGL but they stuff instructions for a requested operation into some sort of stack (usually a FIFO stack) in the rendering thread. The rendering thread runs in a loop and during each iteration it checks it’s event queue (stack) to see if any work needs to be done. If so, it executes the instructions, otherwise it either sleeps for a few microsecs or goes back for another iteration.

There may be some WGL calls (??? wglMakeCurrent()???) that will aide here but I have no knowledge of them. Hopefully someone else that understands this problem will contribute here and we can both learn something.

Multi-threaded programming with OpenGL is not for the faint at heart. I wish you luck.

Paul Leopard

[This message has been edited by pleopard (edited 12-06-2000).]

4

Thanks! I moved the initialisation bit into the thread and it doesn’t crash anymore. Thanks again, cos I had no idea that this could be a problem, although the warning about threads is a bit foreboding, why does no one ever say, ‘Yeah, thats all the hard stuff covered, everything will seem easy now’

5

If that were the case then us engineers and computer scientists wouldn’t get paid so well Hang in there, if you enjoy it it’ll be well worth it.