The DAMAGE Extension
			Protocol Version 1.1
			 Document Revision 1(日本語訳)
			     2007-01-08
			     
			    Keith Packard
			  keithp@keithp.com

			     Eric Anholt
			   eric@anholt.net
		     Open Source Technology Center
			  Intel Corporation
1. 序論

レンダリングによって影響を受ける領域を監視する技術は、スクリーン上の情報をかき集める
VNC のようなシステムから、視力の弱いユーザを補助するためにスクリーンを拡大するアプリケ
ーションに至るまで、幅広く利用されている。この DAMAGE 拡張は、そのようなアプリケーショ
ンが、サーバ=クライアント形式の反応時間(latency)をものともせず、それなりに効率的に動
くようにするために設計されたものである。

2. 謝辞

いつものように、著者は多くの方々から多大な教えを受けている。特に以下の方々に世話になった。

 +	Havoc Pennington。去年、Damage 拡張を設計し実装してくれた。
 	この実装は時の流れの中で消えてしまった。
			    
 +	Bill Haneman。Gnome 環境のアクセシビリティに関する彼の仕事
 	は伝説的だ。

 +	Jim Gettys。様々な状況でクライアントにダメージ矩形の情報を
 	流さずに済ませる方法を見つけてくれた。

 +	Owen Taylor。特定の状況でダメージ矩形の情報が流れることが
 	保証され得るよう提案してくれた。

3.  ダメージ・モデル(Damage Model)

この拡張全体を通じて、ウィンドウ及びピクスマップのピクセルの内容に生じた変更のことを
「ダメージ」(damage)と呼ぶ。「ダメージ」を「ウィンドウ操作の結果生じた缺損やその他のデー
タ消失を補修するため、再表示する必要があるドローアブル領域」と捉える考え方もある。しかし、
この拡張においては、この２番目の考え方は一切使用しない。既存の考え方と容易に混同されない、
より良い用語の提案が熱烈に求められている。

ドローアブルに描画が行われる度に、ダメージが蓄積していく。各描画操作は、ドローアブル内の
１つ以上の矩形領域に「ダメージ」を与える(損傷を与える)。こうした矩形は、各操作で変更され
たピクセルの集合を包含していることが保証されているけれども、変更を受けたピクセル以外のピ
クセルも相当量包含している可能性がある。欲しい物は、報告される矩形の数と包含されてしまう
余分な領域(の量)との間の調和がとれた「ダメージ」である。妥当な着地点は、描画の基本オブジェ
クト(線、文字、矩形)のそれぞれを単一の矩形で表現すること、及び操作の結果のダメージ領域を
そうした矩形の和(union)とすることである。

DAMAGE 拡張のおかげで、アプリケーションは、イベント・データの流れ(stream)の形で未加工の
矩形を受け取ることが可能となり、また、X サーバ内で矩形を部分的に処理させることもできるよう
になる。後者の形式は、転送するデータの量を減らすと同時に、一度再描画操作が始まってしまった
場合の処理待ち時間(processing latency)をも減らすものである。

ウィンドウへのダメージは、ウィンドウ自身の内部で行われた描画と、下位ウィンドウ
(「IncludeInferiors」モードのレンダリング操作において可視状態となるピクセルに影響を与え
るもの)の内部で行われた描画との両方を反映したものとなる。この計算の複雑性を減少させるため、
DAMAGE 拡張は、対象ピクセルの物理的記憶領域に対する全てのレンダリング操作(ウィンドウの境
界内に収まるもの)をサーバが監視することを認めている。これは、単一のフレーム・バッファで全
てのウィンドウを保持するシステムにおいては、ウィンドウの可視部分の内部で行われる全てのレン
ダリング操作でダメージが蓄積することを意味している。

このアーキテクチャを採用した理由は、スクリーンの内容を保持するために複数のピクセル記憶領域
を持つ Composite 拡張を実装できるようにするためである。

3.1 本プロトコルのバージョン 1.1 で追加されたもの

ダメージは、基本的には X のレンダリング操作の際に X サーバによって自動的に計算される。けれ
ども、直接レンダリングを可能にする拡張(訳註：X Rendering Extension？要確認)は、クライア
ントが X サーバの統制の外でレンダリングを実行することを認めてきた。本プロトコルのバージョン
1.1 ではリクエストを１つ追加し、直接レンダリングを行うクライアントがダメージの情報をドロー
アブルへ報告できるようにした。直接レンダリングを行うクライアントの中には、アーキテクチャ上の
制約から、コンポジット用の背面ピクスマップにレンダリングを行うべき場合であっても、常にルー
ト・ウィンドウに対してレンダリングを行う者が存在する。このような場合のレンダリングの誤りを減
らすため、直接レンダリングを行うクライアントは、自身のダメージ領域(の座標等)をスクリーンの座
標空間(の座標等)に翻訳するものとし、ドローアブルに対するダメージではなく、ルート・ウィンドウ
に対するダメージを報告するものとする。

4. データの型(type)

「ダメージ」オブジェクトは、蓄積されたダメージ領域の情報を保持し、ダメージを通知すべきことを
選択されたドローアブル(訳註：ダメージが発生するドローアブル？要確認)と、ダメージ追跡の恩恵を
受けるドローアブル(訳註：ダメージ通知を受け取るドローアブル？要確認)との関係をも映すものとす
る。

5. エラー

Damage
	DAMAGE 型引数の値が定義済みの DAMAGE 型データを指していない場合に発生。

6. 型(type)

	DAMAGE		32-bit の値 (最上位の３ビットは 0 である)
	
	DamageReportLevel		{ DamageReportRawRectangles,
					  DamageReportDeltaRectangles,
					  DamageReportBoundingBox,
					  DamageReportNonEmpty }

	    DamageReportRawRectangles

		スクリーンに変更がある度に DamageNotify イベントを配送する。
		このイベントには、ダメージ領域に外接する矩形境界領域の情報
		が入っている。上に重なっている矩形を押し出す試みは為されな
		い。

	    DamageReportDeltaRectangles

		ダメージ領域には含まれていないダメージが発生する度に
		DamageNotify イベントを配送する。報告される矩形は、同ダメ
		ージ領域の変更を伝えるものにすぎず、未加工のダメージ・デー
		タは含んでいない。
		
	    DamageReportBoundingBox

		ダメージ領域を囲む境界矩形のサイズが大きくなる度に
		DamageNotify イベントを配送する。報告される矩形は、
		ダメージ領域全体を囲うものであり、サイズの変更を生じさせた
		部分のみではない。

	    DamageReportNonEmpty

		ダメージの矩形が「空の状態」から「空でない状態」へ移る度に
		DamageNotify イベントを１つ配送する。また、
		DamageSubtract リクエストの結果が「空でない領域」であった
		時も、毎度 DamageNotify イベントを１つ配送する。

7. イベント

DamageNotify

	level:				DamageReportLevel
	drawable:			Drawable
	damage:				DAMAGE
	more:				Bool
	timestamp:			Timestamp
	area:				Rectangle
	drawable-geometry:		Rectangle

	「more」は、この後すぐに配送されてくる後続のダメージ・イベント
	が存在するか否かを表す。このような後続ダメージ・イベントは、よ
	り大きなダメージ領域の一部として配送されてくるものである。

8. 拡張機能の初期化

クライアントは、DAMAGE 拡張のリクエストを実行する前に、使用する DAMAGE 拡張の版の
交渉をしなければならない。さもなければ、サーバは QueryVersion 以外のいかなる操作に
対しても BadRequest を返すことになる。

QueryVersion

		client-major-version:		CARD32
		client-minor-version:		CARD32

		->

		major-version:			CARD32
		minor-version:			CARD32

	クライアントは、自分が対応している版の中、もっとも大きな版番号をサー
	バに送信する。サーバは、自分が対応している版の中、リクエストの版番号
	の数字を超えない範囲でもっとも大きな版番号を返す。上位の版番号(
	major version)の変更は既存の機能に非互換性を齎すが、下位の版番号(
	minor version)の変更は後方互換性のある変更しか齎さない。クライアント
	は、自分の使おうとしている版と互換性のある版に、サーバが対応している
	ことを確認しなければならない(確認するのはクライントの仕事である)。
	サーバは、DAMAGE 拡張の複数の版に対応するのが望ましい。

9. 監視を可能にする

DamageCreate

		damage:				DAMAGE
		drawable:			Drawable
		level:				DamageReportLevel
		
	ドローアブルに対する変更を監視するためのダメージ・オブジェクトを作
	成する。

DamageDestroy
		damage:				DAMAGE

	ダメージ・オブジェクトを破棄する。

DamageSubtract

		damage:				DAMAGE
		repair:				Region or None
		parts:				Region or None

	以下の方法で同時に領域を変更する：

	    repair が None であれば：

		1)	parts が None でなければ、parts = damage
		2)	damage = 
		
	    repair が None でなければ：
	
		1)	tmp = damage INTERSECT repair(共通領域)
		2)	damage = damage - tmp
		3)	parts が None でなければ、parts = tmp
		4)	damage の残りの領域に関して DamageNotify を生成する

DamageAdd

		drawable:			Drawable
		region:				Region

	drawable で指定されたドローアブルの内部の領域のダメージを報告する。直接
	レンダリングを行うクライアントは、これを用いて、報告しなければサーバが
	気づかなかったであろうダメージを報告することができる。ダメージ領域の座
	標等は、指定されたドローアブルの原点からのものである。

	この方法で送信されたダメージは、通常通り DamageNotify イベントの中に現
	れる。また、同ダメージはサーバ内部のダメージ追跡(影のフレーム・バッファ
	の更新、ピクスマップのダメージ、及びその他の利用に対する追跡)においても
	姿を現す。