Hmm, my post from yesterday seems to be gone. Let''s try it again. Two questions for you guys, - In my application I create the OpenGL rendering context in the main GUI thread (created bij Windows; the thread in which WinMain runs), but I want to use this context from both the GUI thread and some worker threads created later (no gl commands are executed simultaneously at the same time from different threads). How do I share the context between threads? Simply executing gl commands from another thread than the one where the context is created does not work. - Is it possible to do hardware rendering with OpenGL into an invisible buffer? I need the results which I can read back with glReadPixels, but I don''t need a window. I could create a bitmap, and render into that one, but then M$ GDI-generic rasteriser is chosen. This is not what I want, since then I am better off swapping in my own s-buffer software rasteriser. I need this for form factor computations in a radiosity processor. Preferably I also want to force a 24/32-bit color surface, even if the desktop colordepth is only 16 bits. I know all this is possible with Direct3D, but I want the program to be able to run under WinNT and keep the path open to a Linux x86/Solaris SPARC port, so OpenGL is the best choice. Thanks in advance, Bart.

Well, you do ask some good questions there. First of all, I''ve never felt the need to have my rendering going on in another thread - probably the most I''ve done is a dll that did rendering trasparently through D3D or GL.

As for the whole rendering to an invisible buffer, I''ve used things in GL called accumulation buffers that will basically take anything you try to rasterize, figure out the colors after lighting, etc, and just store that info. About rendering to a bitmap, all you would really need to do is select that object into an HDC, set your rendering context to that HDC, and render. Everything then should just magically appear in the bitmap that was selected. The problem there is that the BitBlt is hella slow to get that to the screen, as you''ve pointed out.

Pythius