このアーカイブは同期化されません。 mixi の日記が更新されても、このアーカイブには反映されません。
AWT ライクな描画を実行するためには 1 つ壁がある。
それは、RFB の増分更新要求機能だ。
増分で update を呼びだす場合、
実装者が repaint を呼んだ結果起こる update と、
範囲に関する調整が必要となってくる。
というのも、paint と update には、
その要求範囲に関する微妙な差があるからだ。
JavaSE 6 の Windows 実装で動作を見ると、
paint が発行される範囲は、
常に実際に表示されている領域に対するものになる。
つまり、コンポーネントが部分的にしか表示されてなければ、
その表示されている部分にのみ paint が発生する。
しかし、update は異なっている。
update は、repaint の呼び出しに応じて発行されるが、
実際に表示されているコンポーネントの範囲に関わらず、
常に repaint の引数で与えられた範囲に対して発生する。
これは paint と update の根本となる役割が違うからだ。
paint は、実際の表示状況（外的要因）によって発生するが、
update は、repaint の呼び出し（内的要因）で発生する。
さて、FramebufferUpdateRequest で要求される範囲は、
基本的にクライアントで表示されている範囲である。
要求が増分ではなく完全描画の場合は、
純粋に paint にマッピングすればうまくいく。
しかし増分が要求された場合に同じ方法で update を呼ぶと、
上記の実装と矛盾する結果を生んでしまうことになる。
となると、増分 FramebufferUpdateRequest に対する対応は、
paint や update 等の描画処理とは独立して行う必要がある。
方法としては、サーバ側にある画面バッファの範囲で、
まだクライアントに送信されていない領域を記憶しておき、
増分リクエストがきた際に、要求された領域と、
まだ送信されていない領域を比較することで、
増分（変化した範囲）を検出して送信するという形になる。