run()とpaint()
これまで画面を構成する時は"run()メソッドで数値を動かし、paint()メソッドでそれを動的に反映させる"という手段を取って来ました。
ですが、paint()メソッド内で数値の変動を担当させる事も不可能ではありません。また逆に、run()メソッド内で描画部分迄終えてしまう事も可能です。
しかし、本ビルの講義で扱っている描画方法はrun()に数値を、paint()に描画を担当させる事で一貫しています。
当然ながらこれには理由があります。
1 ― paint()に数値変動をさせない理由
paint()メソッドではダブルバッファリングという技術を用いています。
これは画面描画の際に生じる"ちらつき"を防ぐもので、総てを描き終える迄は描画自体行わない様にして実現させています。
g.lock();

g.unlock(true);
コード内でダブルバッファリングをさせている部分です。画面にlock()でロックを掛け、そのロックがunlock()によって解かれる迄は描画出来ません。
この中で数値変動を行ってしまうと、その演算が終了する迄処理全体が待たされる事になります。
これは処理落ちという結果を招いてしまう恐れがあるのです。
2 ― run()に描画をさせない理由
run()メソッドはスレッドですから、その処理形式は一定の流れを汲んでいます。
描画命令をその中に書き込むという方法は数値の変化を即座に反映させられる事になる為、一見問題無い様に思われます。
確かに現段階ではまだrun()メソッド内で複雑な処理をさせておらず、結果として描画を担当させても構いません。しかしながらこれから先は総ての数値処理をrun()メソッドに担当させて行く事になります。
詳しくは後述の講義を参照して頂きたいのですが、これはcontinueという命令を使って実現させます。
continueを呼ばれた後の処理は反映されない為、本来なら描画するべき部分が飛ばされる危険性があるのです。
今は少し実感が湧かないかも知れませんが、これは後々身に染みて解る様になる筈です。
尤も、慣れてくればこれらは意図して避けられる筈です。が、最初の内は余計な部分でバグを出さない為にも、paint()とrun()の役割はハッキリと区別しておいた方が良いでしょう。
inserted by FC2 system