SAMPLE: Implementing Multiple Threads in an OpenGL Application

Last reviewed: August 5, 1996
Article ID: Q128122
The information in this article applies to:
  • Microsoft Win32 Application Programming Interface (API) included with:

        - Microsoft Windows NT versions 3.1, 3.5, and 3.51
        - Microsoft Windows 95 version 4.0
    

SUMMARY

It is possible to create multiple threads in an OpenGL application and have each thread call OpenGL functions to draw an image. You might want to do this when multiple objects need to be drawn at the same time or when you want to have certain threads perform the rendering of specific types of objects.

This article explains how to obtain GLTHREAD, a sample that demonstrates how to implement multiple threads in an OpenGL application. The main process default thread creates two threads that each draw a three-dimensional wave on the main window. The first thread draws a wave on the left side of the screen. The second thread draws a wave on the right side of the screen. Both objects are drawn simultaneously, demonstrating OpenGL's ability to handle multiple threads.

How to Get the GLTHREAD Sample

Download GLTHREAD.EXE, a self-extracting file, from the Microsoft Software Library (MSL) on the following services:

  • Microsoft Download Service (MSDL)

          Dial (206) 936-6735 to connect to MSDL
          Download GLTHREAD.EXE (size: 28232 bytes) 
    
  • Internet (anonymous FTP)

          ftp ftp.microsoft.com
          Change to the \SOFTLIB\MSLFILES directory
          Get GLTHREAD.EXE (size: 28232 bytes) 
    

MORE INFORMATION

When implementing multiple threads in any type of application, it is important to have adequate communication between threads. In OpenGL, it is important for two threads to know what the other thread is doing. For example, it is common practice to clear the display window before drawing an OpenGL scene. If both threads are called to draw portions of a scene and they both try to call glClear before drawing, one thread's object may get erased by another thread's call to glClear.

The GLTHREAD sample assigns the glClear function to a single thread, and ensures that the other thread does not perform any drawing until glClear has been called. When a menu command message is sent to the main window, the application calls CreateThread twice to create two threads. Each thread calls GetDC(hwndMain) to obtain its own device context to the main window.

Then, each thread calls GLTHREAD's bSetupPixelFormat function to set up the pixel format and calls wglCreateContext to create a new OpenGL Rendering Context. Now, each thread has its own Rendering Context and both can call wglMakeCurrent to make its new OpenGL rendering context its (the calling thread's) current rendering context.

All subsequent OpenGL calls made by the thread are drawn on the device identified by the HDC returned from each thread's call to GetDC(). Now, because only one thread should call glClear, GLTHREAD has thread number one call it. The second thread is created "suspended" so it does nothing until a call to ResumeThread is made. After thread one has called glClear, it enables thread two to resume by calling ResumeThread with a handle to the second thread.

The procedure in the main thread that created the two other threads waits until both threads are finished before returning from the processing of the menu command message that is sent when the user selects the "Draw Waves" menu selection from the "Test Threads" menu. It will use the WaitForMultipleObjects function to do this.


Additional reference words: 3.10 3.50 4.00 95 GDI GRAPHICS THREADS
KBCategory: kbgraphic kbfile kbcode kbwebcontent
KBSubcategory: codesam GdiDrwOpenGL



THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: August 5, 1996
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.