Three Ways to Tackle Multithreading

Three-dimensional rendering often consists of many small tasks that need to be done almost in parallel. To boost performance, all three of the APIs we talk about in this article consist of reentrant code, which makes them well suited to work in multithreaded OSes. However, there are subtle differences in how they handle threads.

OpenGL can handle several program threads, where each thread manages a separate window. Alternately, several threads can divide and conquer an imaging job within a single window. It's important to note that reentrant code by itself doesn't guarantee concurrent graphics processing. The OpenGL commands that control the gra phics state make concurrent pr ocessing possible by saving and restoring the graphics environment for each window as the execution context switches among threads.

Release 1.1 of QuickDraw 3D (QD3D) supports interactive rendering using multiple processors or a multithreaded application. Because QD3D's View class object retains the graphics context, context switches between different graphics states for different threads or different processors are handled automatically. Unlike OpenGL, QD3D has no support for distributed processing over a network, but QD3D's architecture permits third-party plug-ins to do this.

Direct3D supports a multithreaded environment where different applications can draw to different windows simultaneously. It is not optimized for multiprocessing, because Windows 95 is optimized for single-processor systems. Like QD3D, retained-mode objects encapsulate graphics state information. This allows the graphics state of the rendering pipeline's modules to be updated automatically when a context switch occurs between threads that manage different scenes. Applications using the immediate mode must save and restore the graphics state of the pipeline themselves on a context switch.