other versions
- wheezy 4.1.0.20011224-6
DBE(3X11) | X FUNCTIONS | DBE(3X11) |
名前¶
DBE - ダブルバッファ拡張書式¶
ダブルバッファ拡張(Double Buffer Extension, DBE)は、X ウィンドウシステ ムの枠組の中でダブルバッファリングを利用する標準的な方法を提供する。 ダブルバッファリングでは、前面バッファと背面バッファと呼ばれる2つのバッ ファを使用する。この両者ともイメージを保持する。 前面バッファはユーザに見え、背面バッファはユーザからは見えない。アニメー ションの連続するフレームは、前にレンダリングされたフレームが前面バッファ に表示されている間に、背面バッファにレンダリングされる。説明¶
Concepts通常のウィンドウは
XCreateWindow() か XCreateSimpleWindow()
を用いて生成される。
これにより、ウィンドウ属性のセットが割り当てられ、InputOutput
のウィ
ンドウに対しては、イメージを描画する前面バッファが割り当てられる。こ
のバッファの内容はウィンドウが可視状態になったときに表示される。
この拡張により、アプリケーションはウィンドウでダブルバッファを使用でき
るようになる。
これは、背面バッファと呼ばれる2番目のバッファを生成し、ウィンドウの背
面バッファを参照したときに使うため、1つ以上の背面バッファの名前
(XID)
をウィンドウに関連づけることを含む。
背面バッファの名前は、
XdbeBackBuffer
型のドロウアブルである。
DBE
は相対的なダブルバッファリングのモデルを提供する。1つの
XID, つま
りウィンドウは常に前面バッファを参照する。1つ以上の他の
XID, つまり
背面バッファ名は、常に背面バッファを参照する。バッファ交換の後、ウィン
ドウは(新しい)前面バッファを参照し続け、背面バッファ名は、(新しい)背面
バッファを参照し続ける。したがって、背面バッファをレンダリングしようと
するアプリケーションやツールキットは、ウィンドウに対する全ての描画リク
エストについて背面バッファ名を使用する。前面バッファをレンダリングしよ
うとするアプリケーションの一部は、ウィンドウへの全ての描画リクエストに
ついて、ウィンドウ XID
を使う。
複数のクライアントやツールキットは、同一ウィンドウ上でダブルバッファリ
ングを使用することができる。
DBE
はウィンドウがダブルバッファをサポートしているか問い合わせるリクエ
ストと、サポートしている場合に背面バッファ名を問い合わせるリクエストを
提供しない。X
ウィンドウシステムの非同期性により、これは競合状態を起こ
すからである。代わりに、DBE
は同じウィンドウに対して複数の背面バッファ
名が存在することを許す。これらの全ては同じ物理的背面バッファを参照する。
ウィンドウに対して初めて背面バッファ名が割り当てられた時、そのウィン
ドウはダブルバッファを持つようになり、背面バッファ名がそのウィンドウに
対応づけられる。
続いて、新しい背面バッファが割り当てられた時、その新しい背面バッファ
名がウィンドウに関連している場合を除き、ウィンドウは既にダブルバッファ
ウィンドウであり、そのウィンドウは何も変化しない。
ウィンドウが破棄されるか、ウィンドウに対する全ての背面バッファ名が解放
されるまで、そのウィンドウはダブルバッファを持つ。
一般に、前面バッファと背面バッファは同じように扱われる。特に重要な特性
がいくつかある:
ドロウアブルを受け取る関数にウィンドウを渡したときの動作は、この拡張で
も変わらない。ウィンドウと前面バッファは互いに同義である。これは、グラ
フィックスコンテクストが関係していれば
XGetImage() と XGetSubImage()
の意味や、サブウィンドウモードの意味に従うことを含む。ウィンドウが明示
的に XGetImage() や XGetSubImage()
に渡されているかどうか、あるいは明示的に参照されているかどうか(つまり、
祖先ウィンドウが関数に渡された)にかかわらず、前面(つまり可視の)バッファ
が常に参照される。
このため、 DBE
ネイティブのスクリーンをダンプするクライアントは、常に
前面バッファを取得する。
背面バッファに対する
XGetImage() と XGetSubImage()
は、イメージの範囲内にある、背景バッファの隠された領域に対する未定義の
イメージ内容を返す。
背景バッファへの描画は、GC
の subwindow モードが ClipByChildren
である
前面バッファへの描画で使われるはずのクリップ領域を使用する。
ダブルバッファのウィンドウの祖先ウィンドウが
subwindow モードが IncludeInferiors
である GC
を使って描画される場合、ダブルバッファウィ
ンドウの背景バッファに対する影響は、ダブルバッファのウィンドウと祖先ウィ
ンドウの深さに依存する。深さが同じであれば、ダブルバッファのウィンドウ
の背景バッファの内容は変化しない。深さが異なる場合は、ダブルバッファの
ウィンドウの背景バッファの内容は、IncludeInferiors
の描画が行われたピ
クセルについて未定義である。
DBE
で追加される新しいイベントはない。DBE
は XdbeBackBuffer
と呼ばれる新しいドロウアブルのタイプを追加する以外には、現在のイベント
の意味も拡張しない。
リクエストへの応答として、ドロウアブルを含む(例えば
GraphicsExpose)イ
ベント、返り値、エラーが生成された場合、このドロウアブルはリクエストで
指定されたものになる。
DBE
はダブルバッファリングをサポートしているビジュアルを知らせる。
DBE
はタイミング調整や同期の機能は持っていない。このような機能が必要な
(例えば、フレームレートの管理をする)アプリケーションは、X
コンソーシア
ムの標準規約である
Synchronization Extension
を参照すること。
ウィンドウ1つに対しては、1つのバッファだけが同時に可視状態になれる(前
面バッファ)。
ウィンドウに対応づけられているどちらのバッファも、同じビジュアル型、
深さ、幅、高さ、ウィンドウ形状を持つ。
ウィンドウに対応づけられているどちらのバッファも、同じように「可視状態」
(あるいは「隠された状態」)になる。ウィンドウに対して
Expose イベントが
生成されたとき、このイベントは両方のバッファに同じように適用されるもの
と考えられる。ダブルバッファを持つウィンドウが露出したとき、どちらのバッ
ファもウィンドウの背景色で塗りつぶされる。背面バッファが不可視であって
も、隠されるなどの条件は前面バッファと同様に背面バッファにも適用される。
ドロウアブルを引き数に取る関数には、いつ
XdbeBackBuffer
を渡してもかまわない。
これによりアプリケーションは、他のドロウアブルに描画するのと同じように
XdbeBackBuffer
に直接描画することが可能となる。
Window
型の値を引き数に取る関数に
XdbeBackBuffer
を渡すとエラーになる。
XdbeBackBuffer は、Window
型が指定されている返り値、イベント、エラーとして送られてく
ることはない。
バッキングストアやセーブアンダーがダブルバッファのウィンドウに適用され
た場合、これは両方のバッファに同じように適用される。
XClearArea() や XClearWindow()
がダブルバッファのウィンドウで実行された場合、前面バッファと背面バッファ
の同じ領域がクリアされる。
DBE
の基本的な考え方は、どちらのバッファも
X
ウィンドウの管理操作と同
じ方法で扱うことである。
ダブルバッファのウィンドウが破棄されたとき、ウィンドウに関係する両方の
バッファは破棄され、ウィンドウに関係する全ての背面バッファ名は解放され
る。
ダブルバッファのウィンドウのサイズが変更された場合、どちらのバッファも
新しいサイズとなる。ウィンドウのサイズが大きくなった場合、バッファへの
影響は実装がバッファの
gravity
ビット値を尊重するかどうかに依存する。
gravity
ビット値が実装されていれば、両方のバッファの内容はウィンドウの
gravity
ビット値に従って移動し、残りの領域はウィンドウの背景色で塗りつ
ぶされる。どちらの場合も、ウィンドウの背景色で塗りつぶされた領域に対し
て Expose
イベントが生成される。
関数 XGetGeometry() が XdbeBackBuffer
に対して実行された場合、返される
x, y 座標、境界幅は 0
になる。
Shepe 拡張 ShapeRectangles, ShapeMask, ShapeCombine,
ShapeOffset
がダブルバッファのウィンドウに対して実行された場合、両方のバッファは新
しいウィンドウ形状に一致するように変形される。形状の差分
(D = 新形状 - 旧形状)
は、どちらのバッファでもウィンドウの背景色で塗り
つぶされ、D に対して
Expose
イベントが生成される。
DBE
は補助バッファ(例えば、深さのバッファやアルファバッファ)の明示的な
情報は持たず、既定のスワップ動作の制限されたセットしか持たない。アプリ
ケーションによっては、DBE
が提供するよりも高機能のスワップ動作のセット
が必要かもしれない。DBE
の実装によっては、補助バッファの情報を持ち、高
機能のスワップ動作のセットを提供できる。スワップ動作のセットを増やして
連続的に DBE
を拡張する代わりに、DBE
は柔軟な「イディオム」の機構を提
供する。アプリケーションの需要が既定のスワップ動作で満たされた場合は、
それを利用すべきである。そうでない場合は、以下に述べる、複雑なスワップ
動作をイディオムとして表現する方法を使うべきである。この方針に従うこと
によって、幅広い実装に渡って最も有効な性能を保証することができる。
「イディオム(慣用句)」の語が示すように、複雑なスワップ動作はリクエスト
のグループ/列として表される。このリクエストのグループをまとめ、性能を
最大化するため、実装による
atomic
な動作に組み込むことができる。実際に
は最適化のために認識されるこのイディオムのセットは、実装依存である。イ
ディオムの表現と解釈を補助するため、イディオムは次の2つの関数呼び出し
で挟まなければならない:
XdbeBeginIdiom(), XdbeEndIdiom().
開始-終了の組でイディオムを挟んでいない場合は、実装による認識は行えず、
実行性能は悪くなる。
例えば、アプリケーションが2つのウィンドウのバッファを交換し、背面バッ
ファの特定のプレーンだけクリアしようとした場合、アプリケーションは以下
の呼び出しを以下の順序でグループとする:
関数 XdbeBeginIdiom() と XdbeEndIdiom()
はそれ自体では動作は行わない。特定のリクエストのグループ/列をイディオ
ムとして結合することができる実装にはマーカーとして扱われ、そうでない実
装や認識できないリクエストのグループ/列の場合は無視される。これらの関
数呼び出しの順序がおかしい場合や対応が取れていない場合には、エラーは送
られず関数は通常通り実行されるが、性能は悪くなってしまう。
XdbeSwapBuffers()
をイディオムに含める必要はない。例えばスワップ動作
Copied が必要だが一
部のプレーンしかコピーすべきでない場合には、
XdbeSwapBuffers() ではなく XCopyArea()
が使われる。 XdbeSwapBuffers()
がイディオムに含まれる場合、これは
XdbeBeginIdiom()
の呼び出しの直後でなければならない。また、
XdbeSwapBuffers()
がイディオムに含まれる場合、そのリクエストのスワップ動作は正しいが、ス
ワップ動作が他のリクエストと重なっていれば、イディオムの最後のリクエス
トは、別々のリクエストが連続して実行されるように行われなければならない。
例えば、指定したスワップ動作が
Untouched であり、 XdbeSwapBuffers()
の呼び出しの後にウィンドウの背面バッファに対してクライアントのクリップ
長方形を用いた
XFillRectangle()
が行われた場合、新しい背面バッファ(イディオムの後)は、イディオムが実装
に認識されなかったかのようになる。
クライアントアプリケーションが共通のイディオムをカプセル化した1つの手
続きを呼び出せるようになる「簡易」関数を、API
提供者が定義し、アプリケー
ション開発者が利用することが強く求められる。これらの関数は、
XdbeBeginIdiom(), イディオム、
XdbeEndIdiom()
の呼び出しを生成する。これらの関数の使用は、広範囲の実装に渡っての最善
の性能を保証する。
XdbeBeginIdiom().
2つのウィンドウに対する
XID を用いた XdbeSwapBuffers().
どちらのウィンドウもスワップ動作
Untouched を使用する。
片方のウィンドウの背面バッファに対する
XFillRectangle().
もう片方のウィンドウの背面バッファに対する
XFillRectangle().
XdbeEndIdiom().
関連項目¶
XdbeAllocateBackBufferName(), XdbeBeginIdiom(), XdbeDeallocateBackBufferName(), XdbeEndIdiom(), XdbeFreeVisualInfo(), XdbeGetBackBufferAttributes(), XdbeGetVisualInfo(), XdbeQueryExtension(), XdbeSwapBuffers().Release 6.5 | X Version 11 |