C#2.0時代のゲームプログラミング(12) - やねうらおブログ(移転しました)

OpenGLをWindowsプラットフォームで動かすのにwglほにゃららというAPIだけに頼るのは、いかにも心もとない。たとえば、texture自体のHDCが取れない。これは、textureに文字を描こうと思った場合、OpenGL自体の文字を描く機能を用いるのでなければ、いったんどこかに描いて、それを転送しないといけないことを意味する。

.NET Frameworkならば、Graphicsクラスを用いて描画したいので、System.Drawing.Bitmapを生成して、Graphics.FromImageでそのGraphicsオブジェクトを取得。そして文字などを描いたあと、BitmapのLockBitsを用いてlockして、それをglTexSubImage2Dで転送する。

これに要するコストはどうだろう？Bitmapはsurface生成時に一回クリアされるし、そのあと、LockBitsするときもLockBitsが任意のpixel formatでlockできるということから察するに、バッファを確保してpixel formatを変換しながら転送しているということだろう。(一般的に、read onlyではなく、read/writeが出来るsurfaceとしてlockすると、unlockするときに、ここで生成されたテンポラリバッファを元のsurfaceに書き戻すコストもかかる。)

そのあとglTexSubImage2Dもpixel formatを指定できるので、この部分でもpixel format変換が発生している。(だろう)

想像に難くないoverheadだ。しかも、textureはビデオメモリ上にあるので、メインメモリとビデオメモリ間をやりとりしなければならない。これで遅くないはずがない。Win32のBitBltのように、転送元と転送先とのpixel formatを事前に一致させておけばpixel format変換に要するoverheadはある程度避けられると思われるのだが。(つづく)