12 使用上のアドバイス

GLUTプログラムを書くときに心にとどめておいた方がいい多くの点があります． 強く推奨するものもあれば，簡単なヒントや tips もあります.

• ウィンドウのディスプレイ・コールバックにおいて， ウィンドウがドローされる効果を及ぼすようなステートの変更を しないこと．ディスプレイ・コールバックは idempotent であるべき．

• どんなコールバックにおいてでも，レンダリングするのではなくウィンドウを 再描画する必要がある場合は，  glutPostRedisplay （またはオーバーレイへの   glutPostRedisplay）をコールすること． 一般的な規則として，スクリーンに直接レンダリングするようなコードのみが ディスプレイ・コールバックからコールされるべきである； 他のタイプのコールバックはスクリーンへレンダリングするべきではない．

• アニメーション制御のためにアイドル・コールバックを用いる時は， いつウィンドウが完全に覆い隠されるか，あるいはレンダリングの プロセッサ時間を浪費しないためにアイコン化されるか， を決めるのに，ビジビリティ(可視性)・コールバックを使うと良い．

• サブウィンドウの自動的なリシェイプは，GLUT もウィンドウ・システムも 行わない．サブウィンドウがトップレベル・ウィンドウのリシェイプを 反映してリシェイプされるべきならば，GLUT プログラムにおいて 責任持ってこれを行うべきである．

• なるべくカラーインデックス・モードは用いないこと. RGBAカラーモデルの 方がより機能的である上に，カラーマップのスワッピング効果を生じにくい．

• カレント・ウィンドウやカレント・メニューが 定義されていないときは，カレント・ウィンドウや カレント・メニューに影響を及ぼすようなGLUTルーチンを コールしないこと．これは初期化時（あらゆるウィンドウやメニューが 生成される前）に生じやすく，カレント・ウィンドウや カレント・メニューが破壊されてしまう． GLUT インプリメンテーションは警告の出力の義務を負っていない， なぜなら，そのようなルーチンがコールされる度にカレント・ ウィンドウやカレント・メニューがあるかどうかを まず確認しなければならず，オペレーション速度が低下するからである．

• ほとんどのコールバックで, カレント・ウィンドウやカレント・ メニューはコールバックの時点で適切にセットされる （タイマー，アイドルのコールバックは除く）． あなたのアプリケーションが複数のウィンドウやメニューを使う場合， アイドルやタイマー・コールバックにおいて，  glutSetWindow や glutSetMenuを 用いて明示的にカレント・ウィンドウや メニューを設定するように気をつけること.

• 複数のウィンドウに対してひとつの関数をコールバックとして登録した場合， そのコールバック内でどのウィンドウがコールバックを発生させているかを 知るのに glutGetWindowを用いると良い． 同様に，どのメニューがコールされているかを知るのに  glutGetMenu を用いると良い.

• デフォルトでは, タイマーやアイドル・コールバックはポップアップ・ メニューがアクティブの時にもコールされ続ける．遅いマシンにおいては， あるアイドル・コールバックにおける遅いレンダリングはメニューの パフォーマンスを悪くするであろう．さらに，メニューが何か選択された 時に，運動をすぐにストップさせたいような場合，  glutMenuStateFuncを用いて，ポップアップメニューの利用を 追跡するようなメニューへの入/出コールバックを用いると良い．

• 必要以上のインプット・コールバックを選択しないこと． 例えば，（※ マウスの）モーションやパッシブモーションのコールバックが 不要な場合, NULLをそれらのコールバック関数に（※ 引数として） 渡すことで使用不可能にした方が良い．インプット・コールバックを 利用不可能にすることにより，処理されるべきウィンドウシステム 入力イベントをGLUTインプリメンテーションが限定することが可能となる．

• 最小限要求されるフレームバッファ容量が存在するにも関わらず， 全ての OpenGL インプリメンテーションが同じ範囲のフレームバッファ容量を サポートしているとは限らない．  glutCreateWindowや  glutCreateSubWindowが OpenGL インプリメンテーションがサポートしていない初期ディスプレイ・ モードでコールされた場合，fatal error がメッセージとともに 生じるであろう．これを避けるには，  glutGet(GLUT_DISPLAY_MODE_POSSIBLE)を 用いて初期ディスプレイ・モードが その OpenGL インプリメンテーションでサポートされて いるかどうかを確認する．

• バックスペース，デリート，エスケープキーは ASCII キャラクターを 生成するため，押されたかどうかを知るには  glutSpecialFuncではなく  glutKeyboardFuncを用いること．

•  glutSwapBuffersをコールした後は， バック・バッファのステートは未定義になるものと仮定すること．

• あるウィンドウがダメージを受けたら， 付随する全てのバッファはダメージを受けたものと仮定し， 全て再描画すること．

• ダブルバッファ・アニメーションでglutSwapBuffersを使っていない 場合は，レンダリング・リクエストがフレームバッファに確実に発送される ように glFlushを忘れずに用いること． 多くの OpenGL インプリメンテーションが自動的に待機中のコマンドを flush するので，これはそれほど気にしなくてもいいであろうが．

• メニュー（や，分岐しているサブメニュー）を使用している時 （"ポップアップ中"）は，メニューを生成したり破壊したり， メニューアイテムを変更したり加えたり消去したりすることはよくない． メニューのマニピュレーションを避ける時期を知るには， メニュー・ステータス・コールバックを用いること．

• オーバーレイが必要なときに毎回オーバーレイを消去して再構築するよりも， glutHideOverlayとglutShowOverlayを用いて ウィンドウのオーバーレイのディスプレイ・ステートを制御した方が 効率的である．

• 複数の同時にインストールされたオーバーレイ・カラーマップをサポート しているワークステーションは少ない．このため，あるオーバーレイが クリアされたり，あるいは使用されなくなった場合，オーバーレイが アクティブとなっている他のウィンドウが誤ったカラーマップで 表示されるのを避けるために，glutHideOverlay を用いて 隠すのが最良である．アプリケーションが複数のオーバーレイを 使用しているなら，glutCopyColormapを用いて カラーマップの共有を促進した方がよい．

• プログラムに対する GLUT warning や fatal error に遭遇したら， プログラムのどの範囲内でエラーが発生したかを知るために デバッガ・ブレークポイントを   __glutWarning や   __glutFatalError （これらの名前はインプリメンテーションに依存する可能性がある） に設定すると良い．

• GLUT にはプログラムを終了させるための特別なルーチンがない． GLUT を用いたプログラムは ANSI C の exit ルーチンを用いる 必要がある．プログラムが終了する前に何らかのオペレーションを 実行させたい場合は ANSI C  atexit （※ 原文ではonexitとなっているが， これは古い名称であるらしい）ルーチンを用いて exit コールバックを 登録する．GLUT は fatal error が発生した時やウィンドウシステムが プログラムのターミネートをリクエストしたような場合， プログラムを一方的に終了してしまう．このため，exit コールバックとして GLUT ルーチンをコールするのは避けたほうが良い．

• OpenGL が適切に働いていないように見える時は OpenGL エラーを見つける ために必ず，必ず -gldebug オプションをつけること． OpenGL エラーは明示的に要求しないと報告されない.