VirtualGL
しかしながら、OpenGLアプリケーションの実行環境が必ずしもこれらの条件を満たしているとは限らない。さらに、間接レンダリング環境では動作しないOpenGLの拡張機能があることも事情を複雑にしている。こうした拡張機能は3Dグラフィックスハードウェアに直接アクセスする必要があるため間接的に動作させようがないのである。他にも、ユーザのXディスプレイが必要なOpenGL拡張機能をサポートしていなかったり、あるいはその拡張機能がユーザーのデスクトップマシンに無い特定のハードウェア構成に依存する場合もある。
アプリケーションサーバー上でOpenGLレンダリングを実行すれば、アプリケーションから3Dレンダリングハードウェアへの高速で直接のアクセスが可能となり、間接レンダリングでの問題を回避できる。3Dレンダリングをアプリケーションサーバー上で実行すると、ユーザーのデスクトップに送信するのはレンダリング結果である二次元画像のみとなる。画像はその生成に使用された3Dデータの規模に関わらず同じフレームレートで配信できるため、アプリケーションサーバー上で3Dレンダリングを実行してしまえば、三次元描画の性能は問題ではなくなり、二次元描画の性能だけを気にすればよい。つまり、1〜2メガピクセルの画像データをインタラクティブなフレームレートでネットワーク越しに配信すればよいことになるが、たとえばHDTVのような普及している技術でこれは既に可能となっている。
したがってVirtualGLはユーザーのXディスプレイや、VNCなどのGLXに対応していない仮想Xディスプレイ(Xプロキシ)へ、GLXコマンドがネットワーク経由で送信されるのを防ぎ、GLXコールの書き換え時にOpenGLレンダリングの出力先をオフスクリーンピクセルバッファ(Pバッファ)へと変更する。その一方で、アプリケーションのユーザインターフェースを描画する通常のX11コマンドなど、アプリケーションが発行するその他のファンクションコールはそのまま通過させる。
また、VirtualGLの割り込みエンジンは内部処理としてウインドウとPバッファとのマップを保持し、送り先のXディスプレイと3Dレンダリングを実行するXディスプレイとの視覚特性を適合させ、GLXのシームレスな転送を確保できるようさまざまなハッシュ関数を実行している。原則的には、いったんOpenGLコンテキストがアプリケーションサーバのXディスプレイ上に確立されると、その後のOpenGLコマンドはすべてがアプリケーションサーバの3DハードウェアへVirtualGLを介することなく送信されるようになる。このようにして、アプリケーションサーバのハードウェアとドライバが提供している任意のOpenGL機能と拡張機能をアプリケーションが自動的に使用できるようになる。
GLXコマンドの整理とPバッファの管理以外にも、VirtualGLは適切な時間で描画されたピクセル(通常はglXSwapBuffers()やglFinish()によってモニタリングされる)を読み戻し(reads back)、標準的なXの画像描画コマンドを使用してアプリケーションのXウインドウにそのピクセルを描画する。