Safari 4 vs Firefox 4 beta

Spec

• Macbook Pro 13inc
  • 2.66 GHz Intel Core 2 Duo
  • 8 GB Memory
  • Macintosh HD Drive

Firefox 4 beta

============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                  528.6ms +/- 7.3%
--------------------------------------------

  3d:                   108.8ms +/- 30.2%
    cube:                31.0ms +/- 0.0%
    morph:               17.8ms +/- 3.1%
    raytrace:            60.0ms +/- 55.6%

  access:                84.2ms +/- 7.8%
    binary-trees:        19.8ms +/- 2.8%
    fannkuch:            43.0ms +/- 13.7%
    nbody:                8.2ms +/- 6.8%
    nsieve:              13.2ms +/- 7.9%

  bitops:                22.8ms +/- 4.6%
    3bit-bits-in-byte:    0.8ms +/- 69.5%
    bits-in-byte:         8.0ms +/- 0.0%
    bitwise-and:          1.4ms +/- 48.6%
    nsieve-bits:         12.6ms +/- 5.4%

  controlflow:            7.2ms +/- 18.9%
    recursive:            7.2ms +/- 18.9%

  crypto:                37.2ms +/- 4.4%
    aes:                 22.8ms +/- 4.6%
    md5:                  9.8ms +/- 5.7%
    sha1:                 4.6ms +/- 14.8%

  date:                  66.6ms +/- 4.5%
    format-tofte:        43.2ms +/- 3.8%
    format-xparb:        23.4ms +/- 8.1%

  math:                  27.8ms +/- 3.7%
    cordic:              10.4ms +/- 6.5%
    partial-sums:        11.4ms +/- 6.0%
    spectral-norm:        6.0ms +/- 0.0%

  regexp:                41.2ms +/- 13.2%
    dna:                 41.2ms +/- 13.2%

  string:               132.8ms +/- 6.8%
    base64:               8.0ms +/- 61.2%
    fasta:               27.4ms +/- 4.1%
    tagcloud:            42.6ms +/- 6.1%
    unpack-code:         42.2ms +/- 3.8%
    validate-input:      12.6ms +/- 5.4%

Safari 4

============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                  427.4ms +/- 6.8%
--------------------------------------------

  3d:                    58.0ms +/- 20.4%
    cube:                22.8ms +/- 50.9%
    morph:               14.6ms +/- 9.7%
    raytrace:            20.6ms +/- 53.2%

  access:                41.4ms +/- 7.2%
    binary-trees:         8.2ms +/- 36.2%
    fannkuch:            15.8ms +/- 10.3%
    nbody:               10.4ms +/- 18.1%
    nsieve:               7.0ms +/- 41.7%

  bitops:                24.0ms +/- 8.2%
    3bit-bits-in-byte:    3.6ms +/- 18.9%
    bits-in-byte:         8.2ms +/- 19.8%
    bitwise-and:          4.4ms +/- 32.2%
    nsieve-bits:          7.8ms +/- 13.3%

  controlflow:            3.8ms +/- 35.8%
    recursive:            3.8ms +/- 35.8%

  crypto:                28.6ms +/- 39.0%
    aes:                 19.4ms +/- 52.8%
    md5:                  5.2ms +/- 20.0%
    sha1:                 4.0ms +/- 22.0%

  date:                  49.6ms +/- 25.1%
    format-tofte:        28.2ms +/- 21.2%
    format-xparb:        21.4ms +/- 32.5%

  math:                  38.6ms +/- 51.4%
    cordic:              17.0ms +/- 122.9%
    partial-sums:        14.8ms +/- 11.0%
    spectral-norm:        6.8ms +/- 15.3%

  regexp:                15.6ms +/- 4.4%
    dna:                 15.6ms +/- 4.4%

  string:               167.8ms +/- 24.7%
    base64:              34.4ms +/- 68.7%
    fasta:               23.8ms +/- 56.6%
    tagcloud:            29.4ms +/- 16.8%
    unpack-code:         48.6ms +/- 31.9%
    validate-input:      31.6ms +/- 35.9%

withCredentailsの概要

ようするに

var xhr = new XMLHttpRequest();
xhr.open('GET', 'http://www.nicovideo.jp/');
xhr.withCredentials = true;
xhr.send();

とすると、www.nicovideo.jpドメインに自分の持っているwww.nicovideo.jpドメインのCookieがついた状態でGETリクエストが飛ぶという話。

嫌な話

将来的にどうなるのか一切わかんないんだけど、まぁ要するにニコニコの外部プレーヤーって、ログイン済みだとエコノミーじゃなくて普通の動画リソースを返してくれたりするのです。プレミアムだったら高画質とか。

んで、そのためにはCookieが必要なんですが、例えば

var xhr = new XMLHttpRequest();
xhr.open('GET', 'http://ext.nicovideo.jp/');
xhr.withCredentials = true;
xhr.send();

とかしてあると、普通にCookieを送る訳です。この送るCookieにはアクセスしようがないんですけど、返ってくるレスポンスのヘッダにはアクセス出来るのです。

まぁでもSet-Cookieヘッダとかはとれないです。XMLHttpRequestの仕様上。

じゃあ別にいいじゃんとか考えるんですけど、なんかを投稿するAPIとか(はてブなりね)、そういうのがあったりすると、普通にXHRで叩けたりしちゃったりするんじゃないかなと。

まぁでもOriginがきちんと許可されていないとダメなのであんまり効果なさそうなんですけど、例えばアクセス元に応じて動的にOriginを変更するような挙動を入れたりするとアブなさそうです。

そんなことしないとは思うんですけど、上記にあげたように、アクセスするユーザーが持ってるCookieを見て、返すリソースを変えたくなったりとかするかもしれないじゃないですし。

んでもっと厄介なのは、そういう動画とかが置いてある場所はドメインを分けて、無駄なCookieを受け取らないようにしていて、たとえばアクセストークンだけで返すリソースを変えたりとかしてると、そのアクセストークンだけXHRで取得して、トークンをどっかに渡してそのトークンを使ってDL、とかもありえるんじゃないかなーとか考えていました。

結論

Access-Control-Allow-Originは動的に変えない。

前に書いたエントリの通り、withCredentialを付ければCookie情報を付加して通信を行うことができる。

var xhr = new XMLHttpRequest();
xhr.open("GET", "http://other.domain.com/");
xhr.withCredential = true;
xhr.send();

という具合にだ。

んでこれに対してサーバーは以下のようなHTTPヘッダを返す必要がある。

Access-Control-Allow-Origin: http://www.domain.com
Access-Control-Allow-Credential: true

この場合だとwww.domain.comからしか通信は不可能になり、それ以外のドメイン以下の場所からリクエストを発行した場合は通信失敗(status=0)で終わる。

んで、これだと困るといったような人が出てくることも容易に想像が付く。

たとえば、YouTubeの外部プレーヤーとか。related video、つまりはオススメ動画だが、それらに個人の趣味を反映した上でコマーシャル動画をいれたいと思うのは定石だ。その動画との関連だけでなく、そのユーザーがいままでどういった動画をみたかという情報を付与した上でレスポンスを返したい。

が、それはおそらく、やめたほうがいい。

たとえば、*.youtube.comのドメインでCookieが発行されていたとして、api.youtube.comにcredentialでログインCookieを付けて通信を行う。といったようなことをやるとしよう。このログインCookieはアカウントと一対一のハッシュ化されたものだという前提。

これで普通にFlashで通信を行う分にはおそらく問題がない。通信を抜き出したとて、それはアクセスポイントからパケットキャプチャするとかそういうレベルで、それはもはや根源的な問題なのでどうしようもないことだ。とりあえずブラウザレベルで、どうにかできる話ではない。

だが、Javascriptで行うとなれば話は別だ。もはや通信を傍受する必要すらない。単純に通信部分のメソッドを置き換え、自分に都合のいいように別の場所に情報を送ってしまえばいい。

そしてOriginも絶対のセキュリティではなりえない。例えば今のような話を実現するためにはwww.youtube.comにおかなくてはいけなくなるが、そうではなくなるという話。

つまりサービスプロバイダが、外部で自分の所のCookie情報を使うために、リファラやアクセス元を見て、Access-Control-Allow-Originを動的に変化させることもありうるという話。

こいつは実にやっかいで、たとえばXSSは今まではalertが出るぞ！とかのレベルだったおはなしがもっと大変なことになる。XHRからクロスドメインに通信出来るのだから、うっかり下手な所にJavascriptを仕込まれたら、いくらでもセッションCookieが抜き放題になる。今までよりもっとXSSに注意を払う必要があるんではないか。

微妙におかしなことを言っている気がするが、ちょっと頑張ったらこんなことができそうだったという話。気をつけて。

XHR Lv2でクロスドメイン通信が出来るようになった。

コード的には

var xhr = new XMLHttpRequest();
xhr.open('http://other.domain.com/example');
xhr.send();

みたいにするのだけれど、これでアクセスすると、例えばmain.domain.comからつないだとき、.domain.comで登録されているCookieが送信されない。

.domain.comでセッションクッキーを置いておいて、他のドメインにコンテンツを置き、そのセッションのクッキーだけを食わせるというのは結構あると思うのだけれど、それをするためには

xhr.withCredentials = true;

のようにしないといけない。んでここからがハマるところで、

Access-Conrtol-Allow-Domain: *
Access-Control-Allow-Credential: true

のようにしても通信失敗する。これはCredentialがついているときはドメインの指定にワイルドカードが使えないからで、

Access-Control-Allow-Domain: *.domain.com

みたいな指定にしてやるとうまくいく。

でもセキュリティとかの観点から、Credentialを付けないときでも、きちんとアクセス元ドメインの制限はしましょう。

これで2時間ハマったのでメモがわりに。おわり。

だいたいここの通りでいけるんだけど、まぁ自分用のまとめ。

• ビットレートは1500kbps以下。これは全体ではなく動画オンリーであることに注意。音声ビットレートの上限はみてない。128kbpsは大丈夫だった。
• フレームレートは30fpsが上限。ソレ以上の動画ファイルを持っていないので試してないけど。
• 縦横は640×480が上限。どちらも最大値。アスペクト比は1:1推奨？なのかな。よくわからない。
• Profileは今のところBaselineでしか再生試してない。Highはとりあえずダメだった。

一応ビットレートを限界突破する方法として、MPEG ２とかでエンコードするっていう手法はあるんだけど、あの小さい画面で2Mbpsとか出してもどうしようもないと思う。回線圧迫するだけじゃないかな。

Nerineで目指していることとか、ぱっと見ではわかんない機能とかをとりあえず解説しておきたい。解説しておけば誰かが直してくれるかもしれないし。

なんなのか

NerineはS6みたいなものを目指してはいるものの、S6と同じにならないようにしている。例えばS6だとページごとのエフェクトをJSとして書き入れることで、多種多様なエフェクトが使えるのだけれど、Nerineはそういうことが出来ないし、今後もサポートするつもりがない。

Petal

NerineでいうところのEffectというのは、CSSによって定義されたエフェクトになる。これらを僕はPetalと呼んでいて、Nerine本体オンリーだとかなり質素なプレゼンテーションツールなのだけれど(これは意図的で、ネリネの花言葉である簡素に由来する)、Petalを追加することで、そこそこいろいろなエフェクトが使えるようになる。

Webkitレンダラのみ対応しているのはそこが問題で、なんせCSSでアニメーションっぽいことやろうとすると今対応しているのはWebkitレンダラのみだけなので、こういう結果に落ち着いている。

Javascriptによる改造 : Action Petal

Nerineは追加拡張も容易なように作られている。これは僕の趣味みたいなもので、たまに突拍子もないようなアクションをプレゼンに追加したい衝動に襲われることがあるからだ。

例えば現在のページにあるpreでくくられたJavascriptのコードをボタン一発で動かしてみせたいとか程度なら、結構さっさと書いてしまえる。Nerineはキーコンフィグをいじるのも別段苦労しないし、アクションの追加も容易だ。

これらもPetal、拡張の中に収まるだけど、CSSで書くものを僕はEffectPetalと呼んでいて、JSで書くものをActionPetalと呼んでいる。

MVC

こういう構造によってPetal並びにNerineは実現されているので、結果的にプレゼンテーションの本質としての文書はHTML、エフェクトなど見た目的な物がCSS、動きやアクションがJSという形で分離され、双方をつなげるための少しの余分な物だけでつながっている。

多分ボタン一発でプレゼンテーションモードと、普通のページモードに切り替えることも可能に出来るはずだし、それが実装されないなら自前でそういうPetalを書いていしまえばいい。人間はなるべく楽をすべきで、最小の部分は共通化されていた方が楽だ。

Nerineはそういう最小だけ請け負うことにして、あまりリッチにしないでおこうと思っている。僕は派手なのも好きだけれど、紙っきれ一枚にざーっと書いたようなメモも好きだし、どっちかといえばそっちの方が好きだ。

ということで、Nerine作るときに考えていたいろいろと、どうやってNerineを改造するかの話でした。

僕の興味のある事柄は僕以外の何か(誰か、ではない)によって行われて欲しくて、それはなんでかといえば僕自身は情報を手に入れたいが、僕の見える範囲というのはプログラムより狭く、僕の興味のない分野かつ僕が興味を持ちうる分野に大して目が行きにくいから。

今はてなブックマークを使ってWobbuffetというアカウントで自動的にブックマークを行わせている。僕自身のはてぶは2000と少しくらいなのだけれど、Wobbuffetは9000以上のエントリを収集した。僕のブックマークしたものも含めて行っているとして、Wobbuffetは実に7000ものエントリを収集せしめた。

ただこれの精査を行うのが非常に面倒で、よろしくない。もっとなんとかならないものかな。

BMS(だっけ)形式の音ゲーの譜をJSONに変換して食わせてます。タイミングはなるべく音と同期するように作ったけど微妙に速い気がする。ところで僕は音ゲーが苦手なので必死で頑張っても70%で限界です。しかももとの譜は9キーなので実質クリア出来ていない。

まぁそんなこんなで、フランちゃんうふふ。

いつも通りSafariもしくはWebkitレンダラしか想定してません。Firefoxってばmp3再生出来ないんだもん。

• 変換元BMS : http://touhoubms.blog66.fc2.com/blog-entry-64.html
• 背景絵 : http://www.pixiv.net/member_illust.php?mode=medium&illust_id=10189036

最初に画像が読み込まれない場合はリロード。

Canvasに画像を読み込んでその上にテキストを書き込み。URIクエリーパースはコピペ。

ひどいコードになったのでいろんな人から怒られそう。

Firefox3.6で動作検証。’html5.enable’が有効でないと動きません。ムービーのロードに多少時間かかると思うのでしばしお待ちください。

videoの上にSVGを重ねてみたのだけれど、重いのなんのがくがく。

ムービーのロードを待ちながらマウスをぐりぐりやると、結構サクサク黒い丸がついてくるのですが、いざ再生し始めてからぐりぐりしてもがくがく。

なんてこったい。

ここで改めてまとめるのは大変なので、togetterのまとめでもみてもらえれば。

例によってHSP。NicoJKランタイムがないと動きません。http://jk.nicovideo.jp/から落としましょう。

コードしか貼らないのでHSPでなんかexeとかにしないと動きません。HSPを入れましょう。

エラーチェックとかもしてません。広い心を持ちましょう。

#define S_OK    0
#define TRUE    1
#define FALSE   0
#define _IJKNiCOMEvents_GUID    "{E6F90C76-FA3D-4F44-BA23-7D4474BB1B0C}"
#define DISPID_NAVIGATECOMPLETE2    252

// NiCOMを初期化する
newcom nicom,"jkNiCOM.JKNiCOM"
if( stat != S_OK ){
    dialog "NiCOMの初期化に失敗しました。jkSDKがインストールされてないかも。",0
    end
}
screen 0, 880, 680

// コメントウインドウの準備(ウインドウの貼り付け、
cw = nicom("CommentWindow")
mcall cw,"AttachWindowByHandle",hwnd
cw("Transparent") = TRUE
cw("TopMost") = TRUE

sdim channels, 125, 7, 2
channels(0,0) = "4002"
channels(0,1) = "TBS"
channels(1,0) = "4130"
channels(1,1) = "QRR"
channels(2,0) = "4131"
channels(2,1) = "LFR"
channels(3,0) = "4132"
channels(3,1) = "NSB"
channels(4,0) = "4133"
channels(4,1) = "INT"
channels(5,0) = "4134"
channels(5,1) = "FMT"
channels(6,0) = "4135"
channels(6,1) = "FMJ"
chs = nicom("RadioChannels")


cls 4

axobj IE, "Shell.Explorer.2", 265, 680

url = "http://radiko.jp/player/player.html#TBS"
gosub *navigate_ie

comevent ie_event, ie, "{34A715A0-6587-11D0-924A-0020AFC7AC4D}",*event

stop

*navigate_ie
    IE->"Navigate" url
    return

*event
    dispid = comevdisp(ie_event)
    if dispid = DISPID_NAVIGATECOMPLETE2 : gosub *OnNavigateComplete2
    return

*OnNavigateComplete2
    url = IE("LocationURL")
    pDoc = ie("Document")
    name = pDoc("Title")
    delcom pDoc
    id = strmid(url,-1,3)
    title id

    chindex = 0
    repeat 6
        if(channels(cnt,1) == id){
            chindex = cnt
        }
    loop

    comres ch
    mcall chs, "Item", chindex
    mcall cw, "Start", ch
    cw("Visible") = TRUE

    return

音声コーデックがmp3だったら普通にaudioで再生できる訳で、描画に関しては心が折れなければcanvasにがりごり書き込んでいけば、クソみたいに遅いけどまぁ再生はできるんだよなぁとか。

でもそれだとファイル全部ダウンロードしきってからじゃないと再生できないし、そのあともめちゃくちゃ重いしでユーザーは得しないなぁ。

そしてvideoタグ使ってないなぁ……

今度はvideo要素の再生速度を変えてみる。

再生速度を速くすると音が高くなってうんことかを心配したけれど、そんなこともなかったです。大勝利ですね。

サンプルはこちらにおいてありますのでどうぞ。いつもの話ですが、動画再生なのでマシンスペックを食います。ご容赦ください。

動画は例によってvimeoから拝借してきました。Thank you Tom and Matt!!

コードはHTMLの中にあるだけで全部です。

やることはごくごく単純で、videoを再生しながら、videoをソースにcanvasに描画、そのcanvasからbitmap配列をとってモノクロにしてもういっこのcanvasに描画。というだけ。

問題はどう考えても書き方が悪いせいで感動的なほど重いってことです。

Google chrome, safari(多分)で動きます。

http://www.aduca.org/content/html5/video_and_canvas/

動画はここから借りてきました。かっこいい。

iPhone

いわずと知れたiPhoneは現在mp4(H.264)のみ対応。

ただしブラウザ上で再生されるものではなく、タップするとQuickTimeが立ち上がって再生される仕様なので、日本の携帯などと対して変わらない。それに対してなんらかのエフェクトがかけられるとは思えない。

将来的にAppleが対応してくれる可能性がないわけではないし、iPadなどを見る限りそういう流れになってくれるのだろうか？

Android

現在実機では非対応だが、仕様などを見る限り将来的に対応する可能性あり。

ただin fullscreen modeとの但し書きがあるので、iPhoneと同じような実装になる可能性は多いにある。

iPhoneよりは対応の見込み大きいかもしれないな、と個人的に思っている。

むしろ

まだPC用ブラウザでも対応されていないものの、もっとコーデックなどが固まってくれば、一番期待できるのはOpera miniではないかなと勝手に思っている。

Safari、Chromeなどに代表されるWebkit系レンダラを持つブラウザは確かにHTML5の対応速度も早いのだけれど、何にせよ試行的であるし、なによりまだ仕様が確定していない状況でバッドノウハウを溜め込むのは後々良くない影響を及ぼす危険性があると見込んでいる。

まぁでも、最速で新しい技術を試すというのは言い難い快感がある。