素人翻訳

適当に翻訳する。

X11におけるGraphics Context

X11 のグラフィクス・コンテクストは、
・X10 の反省から生まれた。
・描画関数が受け取る引数の中のあるものを纏めたもの。

=====

参考論文
「The X Window System Version 11」
James Gettys、Philip L. Karlton、Scott McGregor
CRL 90/08(６頁、26〜29頁、33〜36頁など)

=====

Graphics Context の狙い

X11 から GC(Graphics Context)の利用が始まった。X10(X バージョン 10)では使われていなかった。X10 では、描画関数を呼び出す度に、必要な情報すべてを引数で渡していた。VAXstation 100 に倣った「state-free」な描画手続きである。このやり方のまま X10 にない描画機能を追加していくと、描画関数の引数が増えすぎる。Xクライアント・Xサーバ間の通信量や、関数インタフェイスの複雑化が問題。

GC を用いた「state-based」な描画手続きだと、
(1)描画リクエストで使う資源の初期化(リソースIDの割当て等)の手間・通信量が減る。
(2)描画リクエストの引数の数が減ることによって、リクエストそのものが小さくなり、Xクライアント・Xサーバ間の通信量が減る。
(3)描画リクエストの関数定義は、引数の数が減ってスッキリする。

XクライアントとXサーバとの接続を表す情報塊の中にウィンドウと描画文脈の情報を含めるかどうか、あるいは「ウィンドウ」を表す構造体の中にグラフィックス・コンテキストを含めるかどうか、検討された。こうしたやり方だと、GCを用いる現在のやり方よりも描画処理のオーバーヘッド(通信量)が一層減るものの、マルチ・スレッド環境への対応が大変で、「ウィンドウ」構造体が大きくなりすぎる。そこで、X11では描画リクエストの度に「ウィンドウ」と「グラフィクス・コンテクスト」を指定することになった。

GC の効果

GC の採用によって、Xlib の描画手続きは一部の引数をプロトコル・リクエストから取得し、残りの引数を同リクエストで指定した GC から取得するようになった。毎度毎度同じ値が指定されるような引数は GC の一部として記録されるようになったので、描画リクエストのサイズが小さくなった。

どの引数を GC に入れ、どの引数を入れないのか、決めるのが大変だった。頻繁に値の変更される引数を Graphics Context に入れてしまうと、GC の内容を変更するリクエストと実際の描画リクエストの二つを描画の度に送信しなければいけなくなる。最終的に現在の23個をGCに入れることにした。Xlib.h の構造体「XGCValues」の通り。フォントなども GC に含めることになった。頻繁にフォントを替える場合には、複数の GC を用意して、描画の度に指定する GC を替えるようにすれば、GCの内容を変更するリクエストを何度も送らなくて済むと考えられた。

GC がなければ、

XFillRectangle(display, drawable, gc, x, y, width, height);

は次のようになっていた。

XFillRectangle(display, drawable, x, y, width, height, function, planemask, foreground, background, tile_or_stipple, ts_x_origin, ts_y_origin, clip_x_origin, clip_y_origin, clipmask);