このアーカイブは同期化されません。 mixi の日記が更新されても、このアーカイブには反映されません。
描画処理をどのようにモデル化すればよいか。
まずは AWT を参考にしてみよう。
AWT では、画面表示が必要になったときに、
特定のメソッドを呼び出して描画を要求する。
言わばオンデマンド描画であり、
画面用のデータを常に保持しているわけではない。
画面の描画に関連するメソッドは 3 つある。
・paint(Graphics g)
・update(Graphics g)
・repaint() // オーバーロード版も含む
このうち、paint や update は、
必要に応じて描画システムによって呼び出され、
実装者が画面を描画するために使うコールバックメソッドだ。
paint は、画面（もしくは画面内の一部領域）を
1 から書き直す時に呼び出される。
つまり、このメソッドが呼ばれた直後は、
画面は「未定義」であると考えることができる。
これが呼び出されるのは、ウィンドウが表示された時や、
他のウィンドウが上に被さって見えなくなった後、
また画面に戻ってきた時、サイズの変更があった時などだ。
このメソッドは、画面表示を修復するために呼び出される。
それに対して update は、現在の画面の状態を保持している。
つまり、このメソッドが呼ばれた直後は、
画面は「以前に描画した状態」であると考えることができる。
これが呼び出されるのは、入力イベントなどによって
ウィンドウに変化が生じ、画面の表示が変化する時である。
そのため、update では変化した部分だけを描画すればよく、
描画のパフォーマンスを向上させることができる。
画面の表示を決めるのは実装者なので、
update が呼び出されるのは、通常、
以下の repaint を呼んだときだけに限られている。
repaint は、直接呼び出すことができる更新要求メソッドだ。
何かの操作によって画面の見た目が変化した際、
それを画面に反映させることを通知するために呼び出す。
repaint は直ぐに update の呼び出しを発行する。
といっても、update はキューに入れられるので、
repaint はすぐに制御を戻し、
update は描画システムから呼び出される。
update によって変化した部分が描画されることになる。
AWT の描画は上記のようなメカニズムである。
実装者がオーバーライドするメソッドは、
update と paint なのだが、
既定実装では update は paint を呼び出す。
なので、一般的には paint を実装するだけで良い。
update をオーバーライドするのは、
キー入力等によって画面が一部だけ変化した場合、
その変化された部分だけを描画する事で、
画面描画の性能を向上を見込む場合である。