Rogue Engineer's Diary / やさぐれ日記

■ [NerdTV] Folklore.orgから: MacPaint Evolution

先日の『NerdTVから:クヌースに「ソース コード見せてよ」と頼まれたら…』で紹介したにもかかわらず、僕はMacPaintを使ったことがない。MacPaintとは一体何者なのだろう、そして1984年に登場した、このとても古い製品を、クヌース先生が2005年に「ソフトウェアの歴史上最も素晴らしいプログラム」と呼んだのは一体なぜなのだろう?

その疑問はAndy Hertzfeldが主宰する、Folklore.orgの中にある 文章"MacPaint Evolution"を読んで氷解した。以下はその日本語訳である。

MacPaint Evolution

Bill AtkinsonがLisaとMacintoshのユーザインタフェースの基礎となった、重要かつ超高速なグラフィックス パッケージ、LisaGraf（後にMac向けにQuickDrawと改名）を開発していたのと同時期に、彼は時間をみつけては、SketchPadと呼 ばれる、Lisaのためのシンプルな、ビットマップベースのドローイングプログラムを作っていた。SketchPadは絵筆やパターンを選択することがで きる、マウスを使った描画ツールであり、LisaGrafに追加された新機能や改良部分をテストしたり、他の人にデモンストレーションするための手っ取り早い手 段を提供してくれていた。

1983年の初めにLisaがAppleの年次株主総会で発表された直後、BillはLisaのシステムソフトウェアの担当から、 Macintosh向けのグラフィックス系のキラーアプリケーションの開発に移った。Steve JobsはBillに、Mark Cutterの作ったLisaDrawのような、構造化ドローイングプログラムを作ってもらいたいと考えていたが、Billは構造化ドローイングプログラ ムは複雑すぎると考えており、もっとシンプルでエレガント、かつ楽しく使えるものを作りたいと思っていた。

彼はまず最初に、古いSketchPadのコードを引っ張り出して、Mac上で動作するように改造し、そのプログラムを MacSketchと名づけた。SketchPadはパターンや線のスタイルを選択するのにメニューを使っていたが、Billはこれを、画面の下のほうに 常時表示されているパレットを使うように変更した。彼はまた、画面の左に大きく目立つパレットを配置し、そこにさまざまな描画ツールを用意した。以後そこ にはさらに多くのツールが追加されることになるが、MacPaintの基本形は、その初期には既に確立されていたのだ。

Billがもたらした最初の大きな進歩は、フリッカー（ちらつき）の排除だった。図形やイメージを画面上でドラッグするときには、移動 後の位置に描画するまえに、これを移動前の位置から消さなければならないが、その際に中途半端に描画された状態が表示されると、目障りなフリッカーとな る。Billはオフスクリーンのメモリバッファに全てを描画した後、これを一気にスクリーンへ転送する方法を使い、中途半端な描画が表示されないようにすることで、 フリッカーを完全に排除した。

実際のところ、Macintoshの厳しいメモリ容量の制限にもかかわらず、彼は二つのオフスクリーンバッファを使っていた。二つの バッファはドキュメントウィンドウと同じサイズを持っており、片方には現在のドキュメントのピクセル情報、もう片方には最後に実行したオペレーションが反 映される前の状態が格納されていた。これにより古いバッファの状態を新しいバッファにコピーするという非常に簡単な方法で、undoが実現できるように なった。またこの方法によりfast drawingも可能となった。オブジェクトが変更される際に、二つ目のバッファにある変更前のドキュメントの状態にアクセスすることは非常に容易であっ たためだ。

基本的な描画更新部分がきちんと動くようになった後、Billはパレットにさらに多くのツールを追加する作業を始めた。彼はユーザがド キュメントの一部に操作を加えることが出来るよう、長方形領域選択ツールを追加した。当初、選択された長方形部分は反転表示で示すようにしていたが、これ は塗りつぶされた面に対しては有効であったものの、選択部分にデジタイズ化された写真のような、複雑なイメージがある場合には見づらくなるという問題が あり、これをなんとかしなければならないとBillは思っていた。

この領域選択の問題を考えていたある日の夕方、彼はLos Gatosにある、ビールとハンバーガーが売り物のレストランに夕食を食べに出た。そこはさまざま客が数十年もの間にも渡り、木のテーブルに刻ん できたイニシャルがそのまま残っているといった雰囲気の、古い店である。ビールを注文し、バーを見回すとHemm'sのビールの看板が彼の目にとまった。その看板に は流れる滝の絵があり、水が滝から湖に流れ込むようなアニメーション効果が施されていた。Billは、看板の表面のすぐ下で移動 するマスク面が、目に触れる場所ごとに違うイメージを表示するという方法により、そのアニメーションが実現されているのだろうと推理した。

彼は突然、この滝と同じようなテクニックで境界線をアニメーション化すれば、バックグラウンドに何があるかにかかわらず選択領域を簡単 に認識することができ、グラフィックスの選択領域の問題は解決できるであろう、ということに気付いた。彼は家に飛んで帰り、交互に表示されるパターンを 使って、彼の見たビールの看板のような、連続した動きを見せるようなアニメーションを実装した。このアニメーションの効果は素晴らしいものであったが、良 い名前が彼には思い浮かばなかった。二日ほど経った後、LisaアプリケーションチームのRod Perkinsにこれを見せると、Perkinsはこの効果がmarching ants（アリの行進）に似ているとBillに言った。Billはこれが気に入り、この"marching ants"を呼び名とすることにした。

1983年の4月ごろ、Billはこのプログラムの名前をMacSketchからMacPaintに変えた。彼は開発のペースを上げ、 一日ごとにMacPaintに新しい機能を追加していった。その中で特に重要なものの一つとして、"Fat Bits"がある。これはドキュメントの一部分を8倍に拡大し、ユーザがピクセル単位で描画することを可能にするものだった。これはオフスクリーンのバッ ファがスクリーンへ転送される際にスケーリング処理を行なうことにより実現されていたため、他の全てのツールや描画効果は、Fat Bitsモードでもそのまま動作させることが可能であった。

もう一つの鍵となる改良は、Billがpaint bucketツールを実装した際にもたらされた。paint bucketはクリック一つで、ユーザの選択したパターンで画面上の領域全体を埋めることを可能にするツールである。これは近傍のピクセルのうち一致する 色を持つものを発見する"seed fill"というアルゴリズムを利用していたが、メモリの制限が厳しいために実装は困難であった。最終的にBillは複数のseed fillアルゴリズムを試験的に実装し、その中で高速かつメモリの利用効率の良いものを一つ選び出す、というやり方によりこの問題に対処した。この seed fillのルーチンは、最終的にMacPaintからQuickDrawへ移動し、128KのROMの一角を占めることになった。

長方形領域選択ツールは有用であったが、イメージの中で任意の形状を持つ領域を選択したくなるような場面も、往々にして発生することがあった。そこでBillは"lasso"と呼ばれる、もう一つの選択ツールを考え出した。"lasso(投げ縄)"という名前は、ターゲットの周囲に巻き つくことから付けられている。ピクセル単位で正確にマウスをコントロールするのは難しいが、lassoツールは選択したいエリアの大まかなアウトラインを 指定すると、白いピクセルを飛ばしてターゲットの周りにきっちりと巻きついた選択領域を自動的に選択してくれる。lassoはpaint bucketの副産物と言っても良い。というのも、paint bucketのために開発されたseed fillルーチンは、lassoツールの巻きつき機能を実現するのにそのまま利用できたからだ。

lassoは画面上の任意のピクセル領域を指定できるが、その実現のためには三つ目のオフスクリーンバッファが必要となった。このバッ ファは ドキュメントウィンドウと同じサイズを持ち、どのピクセルが選択されているかを示すためのマスク情報が格納されていた。このマスクバッファにより、画面上 でイメージをドラッグしたり、lassoで選択された領域をmarching ants効果で目立たせるといった、不規則かつ大きなサイズの領域に対する 高速なグラフィックス処理が可能となった。最初の二つのオフスクリーンバッファは静的に確保されていたが、三つ目のオフスクリーンバッファであるマスク バッファは、他の機能がそのメモリ領域を利用できるように、バッファが利用されていないときにはメモリを解放するようになっていた。

MacPaintはユーザが好きな場所に、好きなフォント、サイズ、スタイルで文字を書けるという点で、テキストを描くのにも優れてい た。だが一旦テキストが描画されると、そのテキストは他の図形と同様、ただのピクセルの集合となるため、これを再度テキストとして編集することは不可能で あった。1983年の6月、これをなんとかしなければならないとBillは考えていた。

Billは、テキストの描かれた領域をテキストツールで選択したときに、ピクセルの集合を文字の集まりに戻す機能を作ることにした。彼 はMacPaintの他のどの機能にも劣らないほどの、精巧なコードを大量に書き上げた。まず最初に彼は、選択領域内にある文字の、個別の長方形領域を取り出 すルーチンをアセンブリ言語で記述した。次に彼は、これら長方形領域のピクセルのチェックサムを計算して、それを既知のフォントに対してあらかじめ計算 されたテーブルと比較する機能を実装した。これにより、チェックサムが一致した場合にのみ、完全な比較作業を行なうという処理が可能となった。

Billの実装した文字認識ルーチンは見事に機能し、以前のMacPaintを使っていた人たちの目には、一度描画されたテキストが再 び編集できる姿はまるで魔法のように映った。もちろんこれも完璧というわけではなかった。というのも余計なピクセルが一つでも文字領域の中に混ざっていると、そ の文字は認識できなかったからだ。とはいえ非常に役に立つものであったことには変わりない。皆、この機能が気に入り、Billが起こした新たな奇跡を祝福 した。

それから数日後、MacPaintから文字認識機能を外すことにしたとBillが言ったとき、僕は耳を疑った。彼が言うに、もしこれを 残しておくと、人々はこの機能をたくさん使うことになるだろう、そうなればMacPaintは優れたドローイングプログラムではなく、出来の悪いワードプ ロセッサとしてとらえられてしまうのではないか、ということを恐れたのだという。今思うと、これはおそらく正しい判断だったのだろうが、当時の僕はそうは 思わ なかった。僕は、多大な努力の下に実装したはずの機能を捨てるという、自身の執着から自らを切り離す彼の姿に驚きを覚えた。多分僕だったらそんなことは出来な かっただろう。

MacPaintは他の主要なアプリケーションにはるか先行して、1983年の10月にはほぼ完成していた。MacPaintの最後の 仕上げは、out of memory問題の発見と対処に費やされた。というのも、MacPaintは自身の持つ三つのオフスクリーンバッファで、Macintoshの128Kの メモリの限界に迫っていたからだ。ワーストケースにおいては、MacPaintのヒープにはたったの100バイト程度しか残らないという状態となった。 MacPaintを動作させている際に僕たちが見つけたバグのほとんどは、メモリ容量の限界に近づいたことにより顕在化した、システム側のバグだった。

MacPaintは現在の基準から言うと、かなり小さいプログラムであるが、Macの持つ128キロバイトのメモリで動作する必要が あった、ということにも触れておきたい。完成したMacPaintは、5804行のパスカルのコードと、それに加えて2738行のアセンブリ言語のコード から構成されていた。コンパイル後の実行コードは、0.05メガバイト以下というサイズであった。

…いかがだろうか。クヌース先生がこれらのアルゴリズムをMacPaintの中に見出した様子を想像するだけでも鳥肌の立つ思いだが、自分が実装した素晴らしい機能を あえて捨てるという判断を下したBill Atkinsonの姿も、言いようがないくらいに印象的だ。Folklore.orgには宝が埋まっている。

本エントリの内容はクリエイ ティブ・コモンズ・ライセンスの下に公開されています