日付：1999/10/20
SETI＠Support-part11(Ver0.5-Part3)2D/3D表示プログラムを別プログラムとして作っていたのはそのほうが気楽だし、実際成功するかどうかわからなかったからでもある。しかし今やだいたい目処は立ち、いよいよ両者を結合しようかという時になった。
それまで従来からあるBitMapのSkyMapを残そうかどうしようか考えていたが、新しい表示になじめないひともいるだろうし、今のSkyMapはそれはそれでなかなか気に入っていたからそのまま残し、デフォルト表示するようにした。となるとBitMapで表示する部分、2D/3Dで表示する部分を切り替えて使うことになる。
さて、一応最初から「いつかは統合するに違いない」と念頭において作ってきたプログラムだが、いざ本当にくっつけようとするとあれやこれやの変更が必要になる。おまけに最初は「本当にできるんかいな」と半信半疑で作っていた物だから、最初のほうに作った部分ほど「後は野となれ山となれ」といいかげんに作ってある。ところが今やちゃんと使おうというのだから、そうしたいい加減な部分をほったらかしておくわけにもいかない。さて、そんなことを考え出すと直す範囲はさらに広がり、いつまでたっても結合の見込みがたたなくなる。
それにくわえて作ってる間から様々な機能が必要であることに気がつきだす。星座を表示するのはいいが、もともとBerkeleyにあったSkyMapはすべてを表示しているわけではない。おまけに人によっては全然星座を表示したくない人だっているに違いない。名前についても同じ様なことだ。そんなことを考えるとメニュー項目が増え、設定項目が増え、そしてプログラムの完成ははるか遠くになっていく。
幸運だったのはその週も仕事は全くなく、会社で大変ひまにすごしていたことだ。そして今やWindows上でも開発ができるので、困る心配はない。写真が載っている（そしてそれが仕事に関係ないことが明な）WebSiteなどがディスプレイ上に表示されていれば仕事をさぼっていることがばれてしまうが、文字がたくさんでているプログラムをいじっていればなかなかばれにくかろう。
その週末、ようやく結合ができかけたプログラムを持ち帰り、Macintoshの上でまた改修を続ける。バグが山のように残ってはいるが、なんとか動く物ができあがったのはその週の週末を半分つぶしての成果だった。全く気候のいい週末に何をしているんだか。
その次の週、プログラムをフロッピに移して再びWIndowsの環境に持っていく。さっそくコンパイルだ。この二つの環境の間での移行は今のところ大変ご機嫌に進んでいる。ソースファイルはテキストだから問題なく移せるのは良いとして、プロジェクトをまとめているファイルがあるのだが、それすらもちゃんと移せるのだ。
さてご機嫌にコンパイルをすると確かにそのプログラムは動いた。そして実にご機嫌に動いた。しばらく私はご機嫌だった。ほーらうごくほーらうごく。しかしそのご機嫌な気分は数秒も続かなかった。
さて、別のタイプのSkyMapに切り替えてみよう、と思ってメニューを選択した。正確に言えば選択しようとした。メニューが表示され、サブメニューを選択しようとしたが、サブメニューはいつまでたっても表示されなかった。プログラムはそこで凍り付いたかのように動かなくなってしまったのだ。
なんだ？これはと思い、あれこれ叩いてみたがプログラムはびくとも動かない。うげげげげげと思いあちこちさらに狂ったように叩いているとそのうち数十秒前に表示させようとしたサブメニューが今になって表示された。いまさらこんなところで表示されてもどうしようもない。いずれにしてもそこから待ったく動かなくなってしまったので、プログラムを正常に終了させることもできない。最近ようやく覚えたタスクマネージャーから強制終了をかけた。正確に言えばその操作すらも容易ではなかったのだが。
それから数度そうした操作を繰り返した。こうした「プログラムいきなり冷凍」という症状は前にも見たことがある。そのときはある条件でData Tableをソートさせると（コードが非効率だったせいで）処理量が馬鹿げて必要となりプログラムがみじんも動かなくなるのだ。
しかしそれは直したはずだ。では何が問題だろう？実はこの前から少しずつ気にはなっていたことなのだが、どうやら今回の改造を考えはじめたときから気になっていたことが現実問題となって目の前に登場してきているようだ。つまりこれまで気にしなかった「性能の壁」というやつである。
ほどなく何故プログラムが凍りついてしまうのか原因がわかった。特にAnalyzing NodeをStringにしている場合に顕著なのだが、SETI@Supportが全体のCPUパワーの大半-97%を消費してしまっているのである。その中でもおそらくはSkyMapの描画にあまりにもCPUパワーをとられているが故にメニューの処理もままならない、ということらしかった。
いつかこういう壁にぶつかるであろう、とｈ予想はしていたのである。今までであれば画像ファイルをぺたっとはりつけるだけでバックのSkyMapは描画できていたのだが、今回は星を数千個のオーダーで書かなくてはならない。おまけに3D画面であれば３角関数を酷使して座標変換を行わなくてはならない。となれば従来より性能が遅くなっても当然である。実際それまでにもいくつか工夫はしていた。視点の位置が変わる間は表示を簡素化するとか、あるいは位置が動かない間はいちいち計算をせずに、一度計算した２Ｄ情報を使って表示するなどである。しかしそれをしてもなおStringsの表示をさせると彼はその描画に没頭しメニューすらうけつけてくれなくなるのだ。
まず私は非常に馬鹿げた対処方法を試しはじめた。Anayzing NodeをString以外のNormal, holeにしている時であれば、メニューなどの表示も（多少遅いが）問題はないレベルである。ということはこのStringsだけなんとかすればいいのかもしれない。もともとこの表示を作った時から「これはべらぼうにCPUを酷使するなあ」と思ってはいたのだが、ことここにいたってはしょうがない。多少表示を荒くしてもなんとかもっと簡単に表示できるようにならないか。
そうおもってあれこれけずってみる。角度の荒さを２倍にしてみたり、あるいは描画の線の数を半分にしてみたりする。すると確かにメニューは動くようになるのだが、表示は似てもにつかない物に変わり果てる。今だかってこの表示を使っている人を見たことがないが、少なくとも作者である私はこの表示をなかなか愛していることに気がついた。変わり果てたStringsを見ると、どうしてもそれらを愛するわけにはいかないことに気がつく。
なおもそうした作業をすること数十分。私は
「ちょっと待て」
と考え出した。仮にここで私があまり表示の質を損なわずにStringsを表示する方法を発見したとしよう。しかしそれが果たして解決策なのだろうか？たまたま私のMachineでは十分な解決かもしれないが、もっとCPUパワーが少なかったり、表示能力が落ちるコンピューター上でも十分な解決と言えるだろうか？問題はもっと別なところにあるのではないか？
そう考えた私は基本に戻ってJavaのAPIを見直しはじめた。特にThreadの部分である。そうすると各Threadの優先順位を設定できる機能があるようだ。描画は今回のプログラムでは独立したThreadで実施している。となれば描画に「専念」してしまうことが問題なのだから、描画のThreadの優先順位を低く設定することが問題の解決につながるのではないか。
そう考えた私はさっそく描画Threadの優先順位を最低に設定してみた。効果はてきめんである。たしか描画のスピードはちょっととろくなったかもしれない。しかしメニューはご機嫌に動くし、それまでSkyMapの上でクリックしデータを選択するのが、ちょっと反応が悪くなっていたのも解消された。またタスクマネージャーで見ると、従来よりもCPUの使用量が４割近く減っていることも確認できた。
メニューが全く動かないことに気がついたときは、「これはまだまだ公開は先かもしれない。あるいはこの性能問題が解決できなければ永遠にこのVer0.5は日の目をみないかもしれない」と悲観的な考えにとりつかれた私であるが、これで一気にご機嫌になった。それからも機能の追加であるとか、バグの修正は延々と続いたが、少なくとも公開する目処はたったのである。
さて、このような経緯を経てVer0.5は１１月１日（とはいっても実際は１０月３１日の夜だが）公開の運びとなった。今明らかに存在している問題として、星座と星の位置が一致していない、というのがある。これに関しては私は匙をなげている。星座のデータは例の場所以外からみつからないし、星はYale Bright Star Catalogueというのからひねりだした。しかし両者はかならずしも一致してない。しかし私にはどちらが正しいのやら間違っているのやらわからない。あるいは単にベースとした年が異なっているだけのことなもかもしれないが、私はわからない。
今回作っては見たが、公開バージョンからは省いてある機能がある（もっともあることをやるとこの機能は使えるようになるのだが）それは"Auto View Angle"という機能である。
もともとこのSETI@Supportを作りはじめたときから、解析が終わって、新しいデータに切り替わるときに、星の爆発のようなアニメーションをつけられないかという考えは持っていたのである。しかしそれはなかなか大変そうであり、かつそのほかにもひっきりなしに問題は発生していたからその考えはゴミ箱の中に放り込まれたままだった。しかし今回View Angleをあれこれいじっていて私はあることに気がついたのである。
3D画面でView Angleを大きくしていくと、だんだんすべての星が視点の中心によっていくように見えてくる。極端な話あるデータを視線の中心に据えてView Angleを１８０度にすると、そのデータだけが見えて、残りのデータはすべて一点に集中し、隠れてしまう。たとえば解析中のデータとView Angleを連動させ、解析が１００％になったところで、View Angleが１８０度になるようにしたらどうだろう。解析が進むにつれて全天の星は一点に集まっていき、新しいデータがきたとたんに、また元のような星空に戻ると。それまでに星が移動したり、View Angleを変えたときには航跡が残るような機能をつけていた。するとうまくすればこれは一点にあつまった星が航跡を引きながら４方８方にとびちり、そして普通の星空になる、という結構面白いアニメーションができるかしれない。
こう考えた私はその構想だけで十分にご機嫌になってしまったのである。そしてしょこしょことコードを書いた。例によって例のごとく、この機能は作ったところでどう見えるかテストできるのは実際に解析が終わったときしかない。となると最近のペースでは１０＋Ｘ時間に一回だ。さて、８月２３日の土曜日、合コンに出席するために実家に返っていた私にその機会が訪れた。機能を作ってから初めての「解析終了、新しいデータの解析開始」が訪れたのである。
私はわくわくしながらその瞬間を待った。SETI@Supportがデータを読みにいくのは５分に一回だから本家のSETI@homeクライアントが新しいデータの解析を初めても、SETI@Supportの表示が切り替わるまでにはいくばくかのタイムラグがある。いまいまかと見つめていると表示が変化した。
もっともこの変化は私が期待したような物ではなかった。いきなりテキスト表示のコンソールが開き「Exception Occured」とかいうメッセージが延々と表示される。ようするにバグが発覚したのだ。私としては見なかった振りをして忘れたかったのだが、親愛なるプログラムは延々と「Exception Occured」を表示してくれる。頭に来た私はプログラムを強制的に終了させた。
表示されたメッセージから見当をつけてプログラムを見てみると、確かに彼には「例外がおこったよーん」と騒ぎ続けるのに十分な理由があることがわかった私は自分の未熟さを呪いながらプログラムを修正した。またAuto View Angleに設定はしたものの、今度この機能の試験ができるのは、今のペースでは２日後だ。。。
さて光陰は矢のごとくすぎさり、再び解析が終了するときがきた。今度こそと思いわくわく画面を見守る。SETI@homeの結果送信、データ受信が終わり、いよいよSETI@Supportのデータが更新される。
その瞬間確かに画面は変化した。今度は「Exception Occured」などと言われることもなかった。そして一応私が意図したとおりにそれまで一点に集まっていた星は普通の星空に戻った。そしてその間航跡も引いてくれた。しかしそれは私が期待したようなかっこいい表示では全然なかったのである。「どっかーん」というよりは「はいはい。わかりましたよ。View Angleを変えればいいんでしょ」といった感じに、大変のんびりと変化したのである。
私は唖然とした。うーむ。この数日頭の中ではかっこいいアニメーションの姿がありありと想像され、「これはひさびさのヒット機能になるかも」と勝手に思っていたのが、全部パーである。私はその機能を深く深く人の目にふれないところに隠すことにした。
さて、かくして新しくなったSETI@Supportは世に放たれることになる。願わくばあまりバグやら問題やらを世の中でおこしてくれないことを。
注釈