X Window System コアプロトコル
一般にグラフィカルユーザインタフェースで「ウィンドウ」と呼ぶものを、X Window System では「トップレベルウィンドウ」と呼ぶ。いわゆる「親ウィンドウ」の「サブウィンドウ」と呼ばれるウィンドウ内ウィンドウも「ウィンドウ」と呼ぶ。ボタン、メニュー、アイコンなどのグラフィカルな構成要素は、実際にはサブウィンドウとして認識されている。
クライアントはウィンドウ生成を要求できる。より正確に言えば、既存のウィンドウのサブウィンドウの生成を要求できる。結果として、クライアントが生成するウィンドウ群は一種の木(階層)を形成する。この木の根をルートウィンドウと呼び、サーバが起動したときに自動的に生成される特殊なウィンドウである。他の全ウィンドウはルートウィンドウの直接的または間接的なサブウィンドウである。トップレベルウィンドウは、ルートウィンドウの直接のサブウィンドウである。見た目で言えば、ルートウィンドウは画面全体と同じ大きさであり、他のウィンドウ群の一番背後にある。
ウィンドウの内容は常に保持されるとは限らない。特に、ウィンドウが移動されたり、リサイズされたり、他のウィンドウの影に隠れたり、完全に(あるいは部分的に)見えなくなったりすると、ウィンドウの内容は破壊される可能性がある。Xサーバが、ウィンドウの内容の「バッキングストア」を管理していない場合はウィンドウの内容は失われる。クライアントはバッキングストアの保持を要求することができるが、サーバが必ずそうするという保証はない。従って、クライアントはバッキングストアを当てにしてはいけない。
クライアントがウィンドウ 0x00200001 の属性変更を要求し、興味のあるイベントとして Expose と KeyPress を受け付けることを宣言する。
クライアントがウィンドウ 0x00200001 の画面表示を要求する。
ウィンドウが画面に表示され、内容を描画しなければならなくなると、サーバはクライアントに Expose イベントを送信する。
このイベントを受けて、クライアントはウィンドウ 0x00200001 とグラフィックコンテキスト 0x00200000 を指定して PolyFillRectangle 要求を送信し、四角形の描画を要求する。
このウィンドウが別のウィンドウに覆われ、再び前面に戻った場合、バッキングストアをサーバが保持していないと、次のようになる。
サーバがクライアントに Expose イベントを送り、ウィンドウを再描画する必要があることを知らせる。
クライアントは PolyFillRectangle 要求を再度送信することでウィンドウを再描画する。
キーが押下されると、次のようになる。
サーバはクライアントに KeyPress イベントを送り、ユーザーがキーを押下したことを知らせる。
クライアントは、それに適切に対応する(この例の場合、終了する)。
ウィンドウ、ピクスマップ、フォントなどに関するデータは全てサーバに格納されている。クライアントはそれらオブジェクトの識別子を知っており、サーバにそれらについて要求する際に名前として使用する。例えば、クライアントがウィンドウを生成したいとき、サーバに対して識別子を指定してウィンドウ生成を要求する。その識別子は後で、例えばウィンドウの描画時などクライアントからの要求で使用される。以下のオブジェクトはサーバ側にあり、識別子を使ってクライアントから指定される。
Window(ウィンドウ)
Pixmap(ピクスマップ)
Font(フォント)
Colormap (色表、後述)
Graphic context(グラフィックコンテキスト)
これらのオブジェクトを「リソース; resources」と呼ぶ。クライアントがこのようなリソースの生成を要求する場合、その識別子を常に指定する。例えば、新しいウィンドウを生成する場合、クライアントはそのウィンドウの属性(親、幅、高さなど)とウィンドウに関連付ける識別子を指定する。
識別子は32ビット整数であり、最上位ビットから3ビットは常にゼロとされる。クライアントごとに識別子の集合を持ち、新しいリソース生成時に使用する。この集合はサーバがコネクションの受理を知らせるパケット内で、2つの整数としてクライアントに通知される。クライアントは指定された範囲から、重ならないように識別子を選択して使う。ウィンドウ、ピクスマップ、フォント、カラーマップ、グラフィックコンテキストについて、2つのオブジェクトが同じ識別子を持つことはできない。
あるリソースが生成されると、その識別子をクライアントが使い、サーバに対してそのリソースに関する何らかの操作を要求するときに指定する。
グラブは即座に効力を発揮する。
この場合、カラーマップは赤/緑/青の光の三原色それぞれに対応した3つのテーブルで構成される。結果として得られるのは三原色それぞれの強さである。このような表現を使う visual class として DirectColor と TrueColor があり、前者はクライアントがカラーマップを変更でき、後者は変更できない。
いずれの機構でも、色をピクセル値で表現するには追加のパラメータが必要である。それらパラメータが visual type として集約されており、visual class の種類、その他のパラメータが格納されている。Xサーバには利用可能な visual type が固定個存在し、それぞれに識別子が割り当てられている。その識別子は32ビットの符号なし整数だが、リソースやアトムの識別子と重なっていても構わない。
クライアントからのコネクションを受理したとき、サーバが送信する受理パケットには、一連のブロックが含まれ、各ブロックは1つの画面(スクリーン)に対応している。各画面に対応したブロックは、さらにその画面でサポートしている色深度ごとのブロックに分かれている。色深度ごとのブロックは可能な visual type のリストを含む。まとめると、各画面には複数の色深度が対応し、その色深度ごとに複数の visual type が対応する。ある visual type は異なる色深度の複数の画面で使える場合もある。