スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

ブラウザの無駄話

インターネットを一般の人も使えるようになった頃、ローカルなPCでやってることをブラウザ経由で全部できるのでは? データはサーバに置けばいいよね? という「ネットOS」なる試みがあった。
Windowsに「Webページをデスクトップに表示」「ファイルをシングルクリックで開く」という意味不明な機能があるのはその名残じゃないかと思ってますが。
話はやっぱりその頃に遡る。NetscapeとMSとがブラウザ機能を拡張しまくって、プラグインアーキテクチャやDynamicHTMLもそのときに生まれた。

ここからはMacの話。
ShockWaveプラグインはそれ自体がメモリの割当を要求し、それだけでMacOS全メモリの半分以上を持っていくようなヘビーなものだった。Macがオンボロというのもあって動作は実に重かった。
永ちゃんのサイトをShockWaveで見て、あまりの重さとつまらなさにウンザリしたのを思い出す。
あの頃からMozilla系のプラグインアーキテクチャは見直されたのだろうかという疑問が、頭から離れない。
いまだにブラウザごと巻き込んで落ちることがあるのは、設計が古いせいなのではという疑問が。

Mac OS Xが出て間もない頃、Carbon化されたGeckoをXULでなくCocoaとリンクしてブラウザに仕立てようというプロジェクトが始まった。
そのキメラなブラウザはFlashでゲームが出来るよう、1秒間に100回近くプラグイン領域のイベントを取りにいって、得られたキー入力をダイレクトにGeckoに回していた。
その結果Flashゲームはプレイできたが、描画がクッソ重いうえに日本語入力が効かなかった。
古いMacではMac OS XにしたときにQuickDrawをGPU描画できなくなったので、Flashの画面エフェクト、例えばフェードアウトやスムーズスクロールがとんでもない遅さになった。
プラグインのようないわば「ウインドウ内ウインドウ」の形を取るアーキテクチャにおいて、イベント確認が存在するとパフォーマンスがガタ落ちする。片方が片方を待つからだ。
Mac版Flashのイベント処理は何か拙い感じがある。クリックした時の反応がそもそも怪しく、イベントがスパッとブラウザ側に通ってる感じがしない。
この辺、MSのIEは妙に質が高いというか、さすがDirectXを作ってるだけのことはあると変に感心してみたり。
あとMac版Flashは描画パフォーマンスがWindows版の半分程度しか出ないうえにGPU支援も限定的だったりする。一度動作ログを見たところ、ずーーっとQuickDrawによる表示色デコードが行われていた。
つまり、Accerate Frameworkがない環境では単純なレンダですらCPUパワーを持っていかれるわけだ。そりゃ遅いわ。

そもそも、アプリの責任においてウインドウ内で何か別のものを動かすというのが地雷原だし、ブラウザを実行環境に見立ててJavaScriptやらの動的なスクリプトを動かすのはエコじゃない。
JavaScriptのパフォーマンス向上手法なんてまんまエミュレーターのそれじゃないですか。JIT、分岐予測、命令のキャッシュ、一括処理。
これだけハードが進歩しているのにブラウザの実行環境ときたら、Win95やPowerMacを思い出させる建て増し環境でマシンパワーを食いつぶしている。すべては利便性のためである、主に開発者の、次にユーザーの。
しかし、そのおかげでプラットフォーム非依存のサービスなりアプリなりを楽しめるわけだから、一種のトレードオフといえないこともない。

comment

管理者にだけメッセージを送る

プロフィール

waverider

Author:waverider

ああ、沖縄に行きたい…

最近の記事
カテゴリー
最近のトラックバック
ブログ内検索
RSSフィード
リンク
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。