Low-level mechanics of glFlush

I’m curious if anyone can give me some low-level descriptions of just what happens during a call to glFlush or SwapBuffers, as I have to locate a crash that’s being caused there.

I’m running Win2k and I’m getting a monster of a crash somewhere during glFlush. If I comment out glFlush, the crash comes in SwapBuffers(). My box dies so horribly, in fact, that the mouse stops responding. This is with Win2k! Is there some kernel object that should be signaled that’s not or some other low-level Win32 api idiosyncrasy that I’m not aware of?

Here’s the situation when it occurs: The app I’m working on was originally a 2d-GDI based app with custom gui work, like, very little windows controls, but multiple windows. My boss wanted me to update some of it from GDI to OpenGL and give it some 3d effects. The problem is, some of the 3rd party code we liscense is GDI based and must remain so, so porting the whole app to OpenGL is a no-go. That means that there have to be seperate windows for the GDI portions and the OpenGL portions. There are a few different portions now using OpenGL which means, you guessed it, I have to manage multiple rendering contexts, one for each window.

Could this have something to do with the crash?

System specs: Win2k (SP2), ATI Xpert 2000 (using the Rage128 PRO AGP 4x chipset), and Borland C++ Builder 4.0

Thank you for your bandwidth,
– Succinct

Hi,
I recall that mixing GDI and OpenGL is a no no. Is it possible that you are mixing GDI and OpenGL? I’m currently working with an app that has GDI and OpenGL. Each window has it’s own DC and subsequently and RC if OpenGL.

Hope this helps.

Lobstah…