このアーカイブは同期化されません。 mixi の日記が更新されても、このアーカイブには反映されません。
RFB のメカニズムを AWT のモデルに近づけるためには、
RFB の描画処理をどのようにマッピングすればよいか。
RFB では FramebufferUpdateRequest メッセージに対して、
サーバが画面のデータをメッセージで返すという流れとなる。
確か、FramebufferUpdateRequest の要求は 2 種類あった。
incremental パラメータの値によって、
完全描画と増分描画の 2 種類の要求方法がある。
■FramebufferUpdateRequest メッセージ
http://mixi.jp/view_diary.pl?id=314140093&owner_id=2300658
incremental = 0 の場合、完全描画の要求である。
これを AWT で解釈すれば、paint コールバックとなる。
incremental = 1 の場合、増分描画の要求である。
これを AWT で解釈すれば、update コールバックとなる。
つまり、FramebufferUpdateRequest メッセージを受けると、
適切な Graphics インスタンスを生成し、
incremental の値によって、
paint と update にマッピングして呼び出せば良い。
paint と update で実装者が描画するため、
FramebufferUpdateRequest では、
実装者が Graphics に描画した内容を元に、
画面データを作成してメッセージを送り返すことになる。
1. FramebufferUpdateRequest 受信
2. Graphics 作成
3. paint or update コールバック呼び出し
4. 画面データを作成して送信
では、repaint の実装はどうすれば良いのか。
通常、repaint は update を間接的に呼び出し、
なるべく速く画面の状態を更新しようとする。
この間接的に呼び出す実装を行うのはかなり面倒なので、
repaint が update を直接呼び出す方法もなくはない。
しかしこの場合、repaint の呼び出しは直ぐに制御を戻さず、
内側で呼ばれる update が制御を戻すまで待たねばならない。
そして、更に考えないといけないのは、
いかにして更新された「増分領域」を記憶するかだ。
repaint では全体を描画するので問題はないが、
update では現在の画素データ上に描画をさせる必要がある。
Graphics には描画機能はあるが、
どこが描画されたかどうかの検出ができない。
でも、RFB で差分を描画させるためには、
どの部分に描画されたのかどうかを判別する必要がある。