2009-06-29
Firefox 3.5正式版のリリーススケジュール
Firefox 3.5は、日本時間ではかなり微妙な時間帯にリリースされることになるようだ。開発総責任者のMike Beltzner氏がMozillaWikiのReleases/Firefox 3.5に書き込んだところによると、リリースのアナウンスは米国太平洋標準時（PDT）で6月30日の午前8時5分と決まった。
日本時間に直すとわずかに30日をオーバーしてしまい、7月1日の午前0時5分となる。当然、日本よりも日付変更線に近いニュージーランドも7月1日のリリースになるわけだ。
中途半端な日時の設定である。6月末のリリースを吹聴し、そこに間に合わせるためリリース候補版の展開に無理を重ねてきたというのに、英語圏のニュージーランドでリリースが7月1日になってしまうのだから。どうせならもう数時間早めればいいのにと思う。
なお、Firefox 3.0.11のユーザーは、リリース当日から手動アップデートが可能である。リリースのアナウンスより少しだけ早く、PDTの午前8時0分、日本時間の7月1日午前0時ジャストにアップデートが始まる予定だ。
（09/06/30追記）わずかに変更された。『Weekly Updates 2009-06-29』参照。
Permalink | コメント(0) | トラックバック(0) | 17:02 
Webブラウザの動作を速いと「感じさせる」ための工夫
MozillaWikiにFirefoxのUIチームが『Perceived Performance』というページを作っている。Firefox.nextの体感速度を引き上げるためのアイデアをまとめたもので、検討中の項目にすぎないとはいえ、どれも採用される可能性のあるものばかりだ。そこで、現在挙がっているアイデアを紹介しておきたい。
- 読み込まれないページのタイムアウトを早める。
- 再起動時のデフォルトとして、現在セッションの復元で使用しているメニューを表示させる（メッセージなどは変更して）。
- メモリ使用量を監視し、たくさんのタブを開きすぎているときは警告する。
- システムトレイに常駐させる機能（Mozilla Suiteにあったものを復活）。
- スロバーの動きを速くする。
- Mac OS X版のスクロールモデルをWindows版とLinux版にも実装する（Bug 462809）。
- リアルタイム戦略ゲームのスタイルのスクロールボックスをコンテンツ領域で使用する。それによって、マウスを動かすだけでページ内を移動できる。
- 戻る・進む処理時のスムーズなアニメーション。ごくわずかなフェードや枠など。
- 何もないところでクリックすると表示されるナビゲーションメニュー。項目にマウスカーソルを合わせるだけでアクションを発行する（モックアップ）。
- 読み込みに時間がかかる場合、ビジュアル上の変化を増やす。たとえば、コンテンツ領域の中央に、大きなすかし状のスロバーを表示させる。
- 検索のためだけにFirefoxをいったん閉じてから再度開くというユーザーのために、Firefox終了後もしばらく動作を継続させる。（スタートページの検索フィールドは知っているが、検索バー、ロケーションバー、ホームボタンなどは知らないユーザーが存在する。）
- ロケーションバーの下に1ピクセル刻みのプログレスバーを付け、処理内容と進行状況を表示。
- スマートロケーションバーの最初の結果にアクセスするために、ユーザが下矢印キーを押さなくてもいいようにする（Bug 410837）。
- ロケーションバーに最初からフォーカスを置き、特定のページへ移動する前にユーザー自らフォーカスを設定しなくていいようにする。
- キャッシュを利用して素早くページを表示しておき、ネットから該当ページを読み込んで準備ができたら、そちらに移行する。また、フォームフィールドをハイライトさせたグレーアウト版のキャッシュページを表示し、ユーザーに情報を再送信したいかどうか尋ねる。
- frecency（訪問頻度や時期から算出）や適応的学習の手法を用いて、ユーザーが訪問するであろうと予想されるWebページをあらかじめ読み込む。
- パスワードマネージャを拡張して、自動ログインを可能にする。
- アップデートのインストールをバックグラウンドのプロセスで行うことで、次回起動時の所要時間に影響を与えないようにする。
- 起動時に最前面のタブを真っ先に読み込む（Bug 496458）。
- 進捗スピナー（スロバー）は200 - 300ミリ秒経過するまで表示しない（現在のように直ちに表示すると待たされる感を与えるため）。
- 新規タブを作成したときに色を変える。
- 起動時の処理順序の見直し。遅延処理が可能なものは後回しに。
- いくつかのタブの読み込みが遅いときのタブの切り替え。
- 履歴の削除に関して、削除したらすぐに一覧から消えるようにし、データベースからの削除はその後行う。
- 他の非同期タスクよりも先にスマートロケーションバーの読み込みを行う。バーがフリーズしたような印象を避けられる。
- 上記タブ切り替えと同様に、特別重いページを読み込み中もタブの切替えができるようにする。
- エラーページをより親切なものに。冷たくて露骨なイメージを持たれないため。
- ページ読み込み中にステータスバーに表示される情報が多すぎるので減らす。
本質的なものから小手先のものまで、興味深い案が並んでいるが、Webページの先読みは物議を醸しそうだ。また、アップデートの適用をバックグラウンドで行うのは、「中断ゼロ」のアップデートという方針に沿うものの、実装は容易ではないだろう。あと、ページナビゲーション機能は、便利そうだがジェスチャ系のアドオンとバッティングしないか心配だ。
Permalink | コメント(0) | トラックバック(0) | 06:14
Firefoxのマルチプロセス化はフェーズ2へ
以前紹介したとおり、Firefox.nextはブラウザのユーザーインターフェイス（UI）を表示するプロセス（クロームプロセス）と、Webコンテンツを表示するプロセス（コンテンツプロセス）を分離する計画になっている。コンテンツプロセスは、「プロセス・オン・デマンド」となり、タブごとにプロセスを割り当てられるようになる。ただ、Google Chrome（以下Chrome）やIE8と同じにするかどうかはまだ確定しておらず、メモリ効率を考えてドメイン単位でのプロセス割り当てにとどめる可能性もある。
他方、mozilla.dev.platformの『Electrolysis update: out-of-process plugins and more』を見ると、プラグインに独自のプロセスを付与することは確実なようだ。Safari 4でも採用されている手法だが、プラグインを独立させることで、Firefox本体がクラッシュに巻き込まれるのを防ぐことができる。
このマルチプロセス化のプロジェクトは、「Electrolysis（電気分解）」と呼ばれ、現在6人以上のメンバーが関与しているが、その一人でFirefoxの主要開発者でもあるBenjamin Smedberg氏によれば、マルチプロセスの恩恵は次の三点だという（『Electrolysis: Making Mozilla Faster and More Stable Using Multiple Processes』）。
- 安定性の向上
- マルチコアプロセッサを活用したパフォーマンスアップ
- セキュリティの強化
ただ、セキュリティサンドボックスの実装は将来の課題とし、クロームプロセス／コンテンツプロセス／プラグインプロセスの分離を優先する。そして、必要なコードすべてを一から作るのでは時間がかかるため、Chromium（Chromeのベースとなるオープンソースのプログラム）からIPC（プロセス間通信）に関する部分を取り入れている。なお、ネットワークライブラリ (Necko) の置換は見送られた。
Electrolysisは4つのフェーズに分かれているが、フェーズ1（7月15日までの完成が目標）の開発成果を示したのが、『Multi-process Firefox, coming to an Internets near you』という記事である。
そこでは、クロームプロセスがコンテンツプロセスから分離されたことが実証されている。mozilla.comを表示させたコンテンツプロセスをコンソールから削除しても、クロームプロセスは残り、復元ボタンを押すと元のページが復活するのだ。これは、FirefoxでWebページを閲覧中にクラッシュに遭遇しても、Firefoxのフレームが生き残っていることを意味している。実際に本体に組み込まれたときは、復元ボタンではなく、「最近閉じたタブ」メニューが使われることだろう。
プラグインに関しても、上の『Electrolysis update〜』によると、Linux上で、ウィンドウモードにおける単一プラグインの単一インスタンスが独立のプロセスで動作しているという。まだNPRuntime（プラグイン向けスクリプト用ラッパー）は実装していないものの、開発メンバーのChris Jones氏いわく、実装にそれほど苦労しないだろうとのことだ。とはいえ、残るウィンドウレスモードのサポートは厄介らしい。
Development Meetingでの発表やSmedberg氏のコメントを見ると、以上の成果をWindowsでも達成した時点でフェーズ1は終了となるようだ。取り組みやすさからこの二つのプラットフォームでの開発が先行したものの、もちろんMac OS Xでも作業は行われる。
次のフェーズ2は、11月1日までの完成が目標となる。まずはネットワーク、履歴やFirefoxの設定などに取り組むとされており、どうやらコンテンツプロセスの複数化に対応していくようだ。つまり、タブごとにプロセスを割り当てても、ユーザーから見たFirefoxの動作が変わらないようにする必要があり、そのための作業を順番に進めていくのである。
ある意味当然といえるけれども、この作業をElectrolysisチーム内だけで完結させることはできない。それを典型的に示しているのが、MozillaWikiの『Multiprocess Images』で、グラフィックスチームが画像キャッシュを改良して、マルチプロセスに対応させる旨を述べたものだ。
現在の仕様のままでタブごとにプロセスを割り当てた場合、画像キャッシュもタブごとに保持することになる。それはリソース的に非常に無駄が多く、パフォーマンスも悪化する。そこで、クロームプロセス内あるは独立したプロセス内に「画像サーバー（imgServer）」を置いてキャッシュを管理し、タブ側の「画像ローダー（imgLoader）」とプロセス間通信を行う予定だ。また、パフォーマンスを考慮し、デコード済みのデータを画像サーバー側で保持して、それをクライアントに渡すことも検討されている。
このように、マルチプロセス化の取り組みはFirefox全体に大きく影響する。思わぬ障害に出くわす可能性も考えられ、フェーズ2が目標どおりの時期に終了するかどうかはわからない。その後はさらに流動的で、ポイントはTrunkに統合される時期だろう。統合直後は拡張機能の互換性が低下すると予測される。さらにマルチプロセス化すればただちにマルチコアのプロセッサ上で速くなるわけではないため、一時的なパフォーマンスの低下もありうる。そうした混乱からいかに早く抜け出せるかが重要といえる。
＜関連記事＞
- Firefox.nextでコンテンツとクロームのプロセスを分離
- Mozilla Links 日本語版『Firefox のマルチプロセス版 Electrolysis の最初の成果』
Permalink | コメント(0) | トラックバック(0) | 06:10
