下に並べた2つの画像は、一方は元画像を縮小後JPEGで圧縮したもの（13,309バイト）。もう一方は元画像をそのままJPEG2000で圧縮した後、先頭の13,307バイトをデコードしてマルチレゾリューションで縮小したものである。
右の画像の、顔のあたりをよくご覧いただきたい。妙なムラが生じている。これがマルチレゾリューションの特性らしい。
JPEG2000のマルチレゾリューションはアニメ絵では使えない。
下に並べた2つの画像は、一方は元画像を縮小後JPEGで圧縮したもの（13,309バイト）。もう一方は元画像をそのままJPEG2000で圧縮した後、先頭の13,307バイトをデコードしてマルチレゾリューションで縮小したものである。
右の画像の、顔のあたりをよくご覧いただきたい。妙なムラが生じている。これがマルチレゾリューションの特性らしい。
JPEG2000の利用可能性を調べた。
使うのはJJ2000。デコーダをjarに固めると148,000bytesになる。ゲーム開始時に必要なイメージファイルはJPEGで200KB程度なので、ロード時間の短縮には役立たない。実際には100KB以上も足が出る。イニシャルロード量にして50%の増大だから、よほどのメリットが必要になる。
どこでそのメリットが出るかといえば、逐次ロードによって、である。想定しうる最大の画面解像度で十分なクオリティを出すには、イメージ1枚当たり50KBを要する。50KBのイメージファイルを10KBまでロードして、残りはゲーム開始後に引っ張ってくる、という戦略である。
高解像度の画像を高圧縮（0.2bpp以下）して展開してみると、激しくモスキートノイズが乗っている。同じデータ量なら、低解像度・低圧縮のほうがいい結果が得られる。モスキートノイズとアニメ絵の相性の悪さは、ただごとではない。ぼかしをかけるくらいの機能があってもよさそうだが、見当たらない。
-Wlevオプションでウェーブレット分解の分解レベルを上げてやると、微妙にマシになるが、大した差はない。
JPEG2000を使わなくても、逐次ロードの目的は達成できる。イニシャルロード用の小さなファイルと、遅延ロード用の大きなファイルを用意しておけばいい。二つのファイルサイズはそれぞれ10KBと50KB、管理の手間を別にすれば、転送量が2割増えるにすぎない。
以上の状況から検討したところ、本作戦においてJPEG2000を用いるメリットはない、との結論に達した。
JJ2000を使って、MSのjview（Version 5.00.3805）とSun JDK1.4のjava（build 1.4.0-b92, mixed mode）の速度を比較した。とあるイメージファイルの圧縮に要した時間を以下に示す。
MS:
real 0m3.585s
user 0m0.010s
sys 0m0.030s
Sun:
real 0m4.276s
user 0m0.020s
sys 0m0.020s
VMの起動時間はといえば、
MS
real 0m0.220s
user 0m0.030s
sys 0m0.010s
Sun:
real 0m0.401s
user 0m0.010s
sys 0m0.030s
MS jview完全勝利。
昨日のアプレットをSun JDK1.4のプラグインで見たら、ろくに動作していなかった。appletviewerでは動いていたというのに。これがあの世に名高いWrite
Once, Debug Anywhereの威力か。
調べてみると、プラグインでは、CanvasにおけるMouseEventのMOUSE_ENTEREDおよびMOUSE_EXITEDをprocessMouseEventに回していない。Componentではちゃんと回しているので、どこかで勝手に消されているのだ。なんて完璧なB・U・G…
それはともかく軽量コンポーネント＋ダブルバッファリング版。今度はSun
JDK1.4のプラグインでも動作を確認してある。
これくらいの速度が出て、フリッカーもなければ、本作戦には十分と思われる。