kazuho.exblog.jp - 奥 一穂の飲んでから書くブログ。なにもかもアルコールのせいです
カテゴリ:Palm & Xiino( 5 )
Xiino の次期バージョン
 社長に教えてもらったのだが、 Software Design の長寿連載「Kyle のシリコンバレー通信」注1で、 Xiino が取り上げられていた。自分が中学生?の頃から読んでいるコラムで取り上げられるってのは、こそばゆい感じであります。

 実は、ここ数日、 Xiino の次期バージョンをどうするか、アイデアを練っている。今のところ、
  • RSS リーダー機能
  • Unicode 対応
あたりを中心に考えているが、海外ユーザーの利用形態が、いまいち把握できていないのが悲しいところ注2。 Kyle さん、RSS リーダー機能、ほしいですか?

注1: Xiino への言及があったのは、2005/10 月号。「~通信」としては第 109 回だが、それ以前にも別タイトルで連載があったはず
注2: 国内ユーザーの希望は Unicode 対応、であってると思う...

[PR]
by kazuhooku | 2005-09-20 11:03 | Palm & Xiino
ACCESS が PalmSource 買収
 げっ、気づいてなかった (汗

 R30 さんに指名されたので、とりあえずショートコメント。

 そもそも、PalmSource の唯一(?)最大の顧客 PalmOne は PalmSource の最新 OS である Palm OS 6 (Cobalt) を採用しないと言っているわけで、今後も ACCESS / PalmSource の成果を採用してくれるかは疑問でしょう。

 となると、 PalmSource が活路を求めようとしていた携帯電話組み込み Linux 系の話になると思います。この分野の海外市場だと、 Opera が強いんじゃないかしら。

 ACCESS としては、 Palm OS のアプリと抱き合わせ販売することで、 Opera に対抗しようとしているんだと思います。

 高いか安いかは知りませんが、とりあえず。
[PR]
by kazuhooku | 2005-09-09 14:29 | Palm & Xiino
Palmscape / Xiino の画像サポート
Palmscape で画像表示が可能になったたのは、確か 2000 年初頭の Version 2.0 においてだったと思う。画像サポートにあたっては、 Palm OS デバイス上で直接 GIF / JPEG ファイルのデコードをせずに、イリンクスで用意した補助サーバを使用して独自形式に変換する方式を採用した。
その理由について、まとめてみる。

  1. CPU パワーの不足。当時の Palm デバイスの CPU (68328EZ/33MHz) では、 160x160 の JPEG をデコードするのに3秒程度かかった。これでは、たとえば XGA (1024x768) の写真データを表示しようとすると、90秒必要なことになってしまう。

  2. メモリ不足。256 色カラーをサポートした IIIc でも自由に使えるワークメモリは 140 KB 程度。画像の展開後のバッファ等も必要なわけだから、このメモリ量で JPEG のデコーダを動かすのは現実的でない。

  3. 同時接続可能な TCP/IP セッションの個数。Version 5 以前の Palm OS では、同時にオープン可能な TCP/IP ソケットの個数は4個だった。この4個の中には、DNS 参照に使用されるソケットや切断処理 (FIN_WAIT) 中のものも含まれるため、実際には HTML と画像を並行してダウンロードすることは不可能である。

  4. 転送データ量の低減。Palmscape では、文字サイズとの兼ね合いから画像を 50%
    に縮小し、かつ、(横スクロールをしないという観点から) 50% に縮小しても画面幅に収まらない画像については、画面幅にあわせて縮小する。また Palm OS 3.5 においては表示可能な最大色数は 256 色だったので、GIF / JPEG より低圧縮率/高速度な圧縮アルゴリズムを使用しても、変換してから転送するほうが、データ量が削減できた。

以上4点だろう。

2004 年末の現在から振り返ってみると、 2 は解決済。1, 3 も解決されつつある (Palm OS 6 で最終解決?) 。残るは 4 のみか。時の流れを感じる。

ちなみに、この補助サーバは大学在学中の 1996 年に書いた finger プロトコルのプロキシサーバを拡張したものである。当時、自分の書いたコードを8年にも渡って使い続けることになるとは思わなかった。

改良すべき点はたくさんあるし、支持してくれるユーザもいる。Xiino の製品寿命は、あとどれくらいなのだろうか。
[PR]
by kazuhooku | 2004-11-14 01:07 | Palm & Xiino
HTML コンパイラとしての Palmscape / Xiino
blog を習慣化するには何回かに分けて書くことができるネタを用意すればいいか、と考えた。

というわけで、 Palmscape / Xiino の実装について、特徴をまとめてみようと思う。

Palmscape のコーディングを始めたのは、たしか 1997 年 5 月。
当時最新の Palm デバイスは 16MHz の Dragonball に 1M のメモリを積んだ PalmPilot Pro 、これが唯一 TCP/IP スタックを積んだデバイスだった。

1MB のメモリといっても、そのうちワークメモリとして使えるのは僅か 10~20 KB。
残りは、読み込み only (書き込みは API 経由) のストレージメモリと TCP/IP スタックが使用する。この僅かなワークメモリで、どのように実用的なウェブブラウザを実装するか、というのが技術的課題だった。

(他製品のソースコードを読んだことがあるわけではないが) 一般的なウェブブラウザの実装は、 HTML から構文木を作成し、その木にレイアウト情報を付加していく、インタプリタ形式 (?) だと思う。

しかし Palm OS のワークメモリでは、 HTML を分割してレイアウト情報を負荷するだけの余裕がない。

必然的に Palmscape は、 HTML を逐次読み込みながら「カーソルを○○に移動して△△を書け」という中間コードへ変換し、ストレージメモリへ保存していく HTML コンパイラとして設計された。

この設計が、良くも悪くも Palmscape / Xiino の特徴となっている。良い点としては、

+ ワークメモリより大きな HTML ファイルを表示できる
+ ダウンロード終了後は中間コードを実行するだけなので、表示/スクロールが早い
+ 余計なタグ情報を保存しないので、ダウンロード後のサイズが小さい

等が挙げられる。当時の HTML は単純であったことから、コンパイラ型という選択は正しかったと思う。しかし、今日の複雑化した HTML では、デメリットも少なくない。

たとえば、テーブル等2パスのレンダリングが必要な場合 (1パス目でテーブルのセルの幅を決定し、次にレンダリングを行う) は、メモリの節約にはならないし、ダウンロード時にレイアウトが固定化されてしまうので、 JavaScript を用いてオンデマンドに画像を差し替えるといったことは困難である。

また、ワークメモリも増加し、コンパイル型を選ぶメリットは小さくなった。

今、仮に、1からブラウザを作るとしたら、コンパイラとインタプリタの双方の特徴を併せ持ったハイブリッドとして実装するのがベストな選択なのではないだろうか。

次回は、画像サポートについて書いてみたいと思う。
#その次は JavaScript?
[PR]
by kazuhooku | 2004-11-05 01:04 | Palm & Xiino
ひさしぶりの Palm プログラミング
ひさしぶりに Palm のコードを書きました。
Xiino/3.3 リリースのためです。

JavaScript まわりで、かなり痛いバグがあったりしましたが、全部直して一息... と思いきや、リリースしたソフトのバージョン番号が間違っていました。

正式版なのに、 3.3b1...
b0057078_2041926.gif


...ま、いっか。

次はランドスケープモード (横方向 480 ピクセルモード) を追加しようと思ってます。簡単にできそう。
[PR]
by kazuhooku | 2004-11-02 20:20 | Palm & Xiino