Hebikuzure's Tech Memo

2009年12月5日

開発者のための IE9 の初期的概観

Filed under: Internet Explorer — hebikuzure @ 10:06 AM

An Early Look At IE9 for Developers
http://blogs.msdn.com/ie/archive/2009/11/18/an-early-look-at-ie9-for-developers.aspx

順序が入れ替わってしまいますが、IE9 についての記事が出ているので先に訳出します。
この間のリリース ペースからすると、IE9 は来年末か再来年前半くらいからベータテスト、再来年後半かその次の年にリリース、さらに次期バージョンの Windows にも搭載、ってスケジュールでしょうか。

以下の文章は IE Blog の 11/18 の記事 An Early Look At IE9 for Developers を hebikuzure が私的に試訳したものです。翻訳については Microsoft Corporation およびマイクロソフト株式会社とは無関係に hebikuzure が公開情報に基づき独自に行ったものであり、この文書の内容についての文責は公開者である hebikuzure にあります。翻訳の内容および技術的内容については正確を期すよう十分な注意を払っておりますが、誤りや不正確な部分が含まれている可能性がありますので、本文書を利用される際には原文も併せてご確認ください。


開発者のための IE9 の初期的概観

Windows 7 の出荷開始からほぼ 1 月経ちましたので、開発中の Internet Explorer 9 について初期的な概観を紹介したいと思います。

本日の PDC では、パフォーマンスや標準との相互運用性の向上について紹介するとともに、IE と Windows が、Web 開発者が PC のハードウェアの能力をブラウザーで利用できるようにする方法についても示しました。特に、他のブラウザーでは現時点で行われていない、Web ページのテキストとグラフィックスのすべてに対するハードウェア アクセラレートされたレンダリングを実演しています。Web サイトの開発者はサイトを書き直すことなくパフォーマンスが向上し、その他にも利点がある事を実感するでしょう。

パフォーマンスの向上。ブラウザーのパフォーマンスには、ブラウザー内のさまざまな異なるサブ システムが含まれます。異なるサイト – あるいは同じサイト内での異なる動作 – はブラウザーに異なる負荷と要求をかけます。

例えば、ユーザーには同じように見える二つのニュース サイトが非常に異なるパフォーマンス特性を持っている場合があります。これは開発者がサイトをどのように構築したのかにより、一方のサイトでは Javascript エンジンと DOM に時間の大半が使われ、もう一方のサイトではレイアウトとレンダリングで多くの時間が使われるからです。サイトが単なるページというより “アプリケーション” である場合 (例えば Web ベースの電子メールや、Office Web Apps など)、ユーザーの操作によりまったく異なった方法でブラウザーのサブ システムが動作させられます。下のグラフは異なるサイトでそれぞれどれだけの IE のサブシステムが使われたのかを示しています。一例として、ある主要なニュース サイトではスクリプト エンジンとマーシャリング (整列化) に多くの時間が使われているのに対して、別のサイトではスクリプトとレンダリングに多くの時間が使われており、また Excel Web App ではスクリプトの実行にはほとんど時間が使われていません。

このグラフではそれぞれのサブシステムで使われた時間の合計をパーセントで示しており、サイト間の時間の比較ではありません。これはブラウズで使われる主要なサブシステムに焦点を合わせており、ブラウザーの “フレーム” の機能 (アンチ フィッシングなど) や IE のプロセス内で実行されるサードパーティー製のソフトウェア (ツールバーや Flash のようなコントロール) は含まれていません。またネットワーキングについても、ユーザーのネットワーク速度に依存するため取り除いています。またサイトのプロファイルはシナリオにより顕著に異なることにも留意してください。例えば Excel Web App でファイルをロードする時のプロファイルと、シート上で選択操作をする際のプロファイルは非常に異なっています。

スクリプト エンジンはこうしたブラウザーのサブシステムの一つに過ぎませんが、数多くのスクリプト パフォーマンスのベンチマークが存在しています。スクリプト パフォーマンスのテストでよく使われるのは Apple’s Webkit team のものや SunSpider です。次のグラフは同じコンピューター上で異なるブラウザーの SunSpider テストを行った際の相対的なパフォーマンスを示しています。

IE7 と主要なブラウザーの “最新版” に加え、主要なブラウザーの “開発中” の出荷前バージョンも含めています。Windows 7 に含まれる IE8 のリリースからひと月しか経っていませんが、開発中のバージョンの IE はすでに仲間はずれの性能ではありません。

差異がこれほど小さくなると、その差には意味がありません。パフォーマンスに関与する他のサブシステムがより重要になり、実際のサイトでその違いに気づくのは難しくなるでしょう。とは言え、我々は引き続きスクリプト パフォーマンスの改善に努めるでしょう。

我々は実際のサイトで使われるブラウザーの全てのサブシステムのパフォーマンス特性を考慮しています。我々の目標は幅広い現実のサイトでのより良いパフォーマンスであり、ベンチマーク結果ではありません。

標準準拠の向上。我々は相互運用可能な方法で、- 多くの開発者が利用したがっているような – リッチな機能を提供することに集中しています。開発者は、優れたアプリケーションやエクスペリエンスのためより良い機能を求めていますが、同時にその機能が、サイトを何度も書き直しテストし直すことが無いよう相互運用可能な方法であることを望んでいます。標準化のプロセスは、この目標にとって良い手段です。

技術者として進歩を成し遂げたいと思ったとき、我々は機能について幅広くかつ奥深く検証するテスト スーツを開発しました。IE8 では、我々は CSS 2.1 の高度な相互運用性のある実装を行い、また W3C に 7,200 以上のテストを提供しました。バリデーション テストに含まれていない標準を首尾一貫して実装するのはとても難しく、開発者が信頼することも困難です。

Acid 3 のようないくつかの標準化のテストは、いくつかの欠点があるにもかかわらず、標準準拠の簡単な指標として広く利用されるようになりました。Acid3 は (その多くはまだ標準化の “working draft” 段階にあるような) さまざまなテクノロジーについて、多くの先進的な事例やエラー条件を含む、およそ 100 の側面をテストします。これは最新のビルドの IE9 で Acid3 を実行した結果です:

我々はサイト開発者が利用するテクノロジーに対する IE でのサポートを強化しているので、このスコアは継続的に向上しています。(Web 開発者の視点から) より有意義な標準サポートの事例は丸角です。これは IE9 が下にあるマークアップに従って丸角を描いたところです:

Web 開発者にとって重要なもう一つの標準サポートの実例は CSS3 セレクターです。以下は Web 開発のコミュニティーの皆さんが css3.info にまとめたテスト ページです。これはよく考えられたテストの優れた例で、このうちの一つは IE8 のリリース以降の我々の進歩を示しています:

このようなコミュニティーによるテストの努力は役に立ちます。最終的には、我々はコミュニティーや W3C やその他のワーキング グループの皆さんと共に、CSS 2.1 に向けて一緒に作業したのと同様、開発者にとって重要な標準のための、真のバリデーション テスト スーツ策定の作業をしていきたいと思っています。例えばこのリンクは HTML5 の storage API の一つのテストで、(IE8 を含む) いくつかのブラウザーは現在対応していますが対応していないブラウザーもあります。

ここでの作業は、製品自体にとってもテスト スーツにとっても、開発者が信頼できるリッチな相互運用性のあるプラットフォームという目的を達成するための手段です。

コンピューターのハードウェアと Windows のパワーを開発者がブラウザー中で利用可能にする。Windows を巡るコンピューターのプラットフォームとエコシステムは驚異的なハードウェアの進化をもたらしました。ブラウザーはこうしたハードウェアの進化のメリットを Web 開発者が発揮できる場となるべきです。

我々は、Web 開発者にとって多くの利点が得られるよう、IE で Windows API の DirectX ファミリーを利用するよう変更しています。出発点は、Direct2D と DirectWrite を利用してすべてのグラフィックとテキストのレンダリングを CPU からグラフィック カードに移すことです。ハードウェアによるグラフィック アクセラレーションは、リッチでグラフィックを多用したサイトが、より少しの CPU 利用でより早く表示されることを意味します。(このインタビューにいくつかの事例のスクリーン キャプチャーが含まれています) これにより Web 開発者は今までやっていたのと同じ相互運用性のある標準的なパターンでサイトを作成し続けながら、ハードウェア エコシステムの進化のメリットを享受できるようになります。

パフォーマンスの向上だけでなく、このテクノロジーはサブピクセル ポジショニングによるフォント品質と可読性の向上にも寄与します:

96 ポイントの Gabriola フォントを Lenovo X61 ThinkPad 100% のズームで GDI を使って表示 (ジャギーあり)

96 ポイントの Gabriola フォントを Lenovo X61 ThinkPad 100% のズームで Direct2D を使って表示 (ジャギーなし)

先週、Channel 9 はエンジニア チームの何人かにインタビューをしています。インタビューのビデオは以下で視聴できます:

Introduction, and Interoperable Standards (序論、および相互運用性のある標準について)
Early look at the Script Engine (スクリプト エンジンの初期的概観)
Hardware accelerated graphics and text in the browser via Direct2D (Direct2D によるブラウザーのテキストとグラフィックのハードウェア アクセラレーション)

我々はまだ製品開発サイクルの初期段階にありますが、開発者の皆さんに向けて我々のアプローチとさらなる進歩について明確にしたいと思います。我々は IE8 の製品サイクルからフィードバックを受け、次のバージョンの IE で期待に添えるよう注力していきます。

ありがとうございました。
Dean Hachamovitch
ゼネラル マネージャー、Internet Explorer

コメントする »

まだコメントはありません。

RSS feed for comments on this post. TrackBack URI

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

WordPress.com Blog.

%d人のブロガーが「いいね」をつけました。