2014年09月21日

v3.4.1の速度測定結果

続いてv3.4.1時の速度測定結果を記載します。

MacBook Pro 13" Retina
ブラウザ正答判定全盤面描画(SVG)リサイズ時描画(SVG)全盤面描画(canvas)リサイズ時描画(canvas)
Safari 7.0.2 0.11ms 0.92ms 22.33ms 3.20ms 4.03ms
Chrome 39 canary 0.13ms 0.94ms 22.79ms 3.34ms 4.39ms
Firefox 32.0.1 0.23ms 0.98ms 15.09ms 16.46ms 18.52ms

MacBook Pro 13" Retina (Windows 8.1 on Parallels)
ブラウザ正答判定全盤面描画(SVG)リサイズ時描画(SVG)全盤面描画(canvas)リサイズ時描画(canvas)
IE11 0.27ms 2.67ms 42.19ms 6.91ms 8.36ms
IE11 (IE10 mode) 0.59ms 10.23ms 96.79ms 8.55ms 10.51ms
IE11 (IE9 mode) 0.60ms 9.92ms 96.79ms 8.55ms 10.32ms
Opera 12.17 0.42ms 1.76ms 16.50ms 9.80ms 11.74ms
Firefox 32.0.1 0.30ms 1.05ms 17.96ms 20.74ms 23.46ms
ブラウザ正答判定全盤面描画(VML)リサイズ時描画(VML)
IE11 (IE8 mode) 0.57ms 8.14ms 539.83ms
IE11 (IE7 mode) 0.58ms 8.28ms 531.43ms

タブレットその他
ブラウザ正答判定全盤面描画(SVG)リサイズ時描画(SVG)全盤面描画(canvas)リサイズ時描画(canvas)
iPad Air + Safari 7.0 0.30ms 2.62ms 68.91ms 6.51ms 12.28ms
iPhone 4 + Safari 5.1 10.05ms 46.37ms 361.08ms 127.46ms 166.03ms
Nexus 7 + Chrome 37 1.15ms 10.66ms 244.40ms 53.20ms 63.31ms
Nexus 7 + Firefox 32.0.1 2.04ms 8.09ms 170.39ms 150.35ms 160.46ms
F-01F + Android標準ブラウザ 4.2 2.06ms 15.75ms 121.23ms 53.25ms 66.23ms
F-01F + Chrome 37 0.88ms 8.66ms 163.21ms 41.95ms 45.92ms
F-01F + Firefox 32.0.1 1.69ms 6.65ms 111.88ms 111.39ms 107.80ms
WiiU 5.42ms 22.17ms 234.95ms 77.45ms 85.94ms
3DS 164.00ms - - 2071.20ms 2172.60ms

SVGの描画速度は大幅に改善できました。リサイズ時はちょっと遅くなっていますがまぁいいかな、、
で、なぜかcanvas描画の方も改善している
Chromeの速度が復活しています。また、Firefoxも多少動作速度の改善が進んでいる様子ですね。
posted by はっぱ at 02:54| Comment(8) | TrackBack(0) | プログラム

描画speed調査 ぱずぷれv3.4.0

ぱずぷれv3.4.1で描画ルーチンをかなり修正したので、v3.4.0, v3.4.1の描画速度調査結果を記載します。
MacBook Pro 13" Retina
ブラウザ正答判定全盤面描画(SVG)リサイズ時描画(SVG)全盤面描画(canvas)リサイズ時描画(canvas)
Safari 7.0.2 0.21ms 15.25ms 31.63ms 3.02ms 4.05ms
0.23ms 20.15ms 25.98ms 4.04ms 4.38ms
Chrome 35 canary 1.05ms 17.49ms 35.22ms 6.11ms 6.28ms
Firefox 27.0.1 0.45ms 6.56ms 20.04ms 20.49ms 21.73ms

MacBook Pro 13" Retina (Windows 8 on Parallels)
ブラウザ正答判定全盤面描画(SVG)リサイズ時描画(SVG)全盤面描画(canvas)リサイズ時描画(canvas)
IE11 0.36ms 24.00ms 41.22ms 8.35ms 12.24ms
IE10 0.60ms 42.10ms 38.31ms 13.79ms 11.52ms
Opera 12.16 0.85ms 7.44ms 20.64ms 11.68ms 13.14ms
Firefox 27.0.1 0.49ms 6.21ms 24.24ms 28.60ms 31.22ms
ブラウザ正答判定全盤面描画(VML)リサイズ時描画(VML)
IE10 (IE8 mode) 0.65ms 78.91ms 333.12ms
IE10 (IE7 mode) 0.64ms 87.63ms 377.12ms

6年前のLet's note (Core Solo + Windows XP)
ブラウザ正答判定全盤面描画(VML)リサイズ時描画(VML)
IE6 (IE Collection) 174.59ms 1014.60ms 2603.30ms
IE8 30.52ms 657.80ms 917.20ms
ブラウザ正答判定全盤面描画(SVG)リサイズ時描画(SVG)全盤面描画(canvas)リサイズ時描画(canvas)
Firefox 2.0.0.20 27.52ms 84.31ms 382.66ms - -
Firefox 3.0.18 12.64ms 37.59ms 255.42ms - -
Firefox 3.6.28 8.58ms 28.84ms 141.66ms 121.43ms 129.72ms
Firefox 28.0 1.53ms 17.11ms 65.49ms 83.15ms 90.51ms
Chrome 33 4.60ms 61.92ms 106.30ms 29.42ms 31.95ms
Safari 3.2.3 14.40ms 79.86ms 153.33ms - -
Safari 5.1.7 3.65ms 25.26ms 71.18ms 41.32ms 47.22ms
Opera 12.16 3.29ms 22.68ms 63.07ms 45.02ms 50.13ms

タブレットその他
ブラウザ正答判定全盤面描画(SVG)リサイズ時描画(SVG)全盤面描画(canvas)リサイズ時描画(canvas)
iPad Air + Safari 7.0 0.62ms 41.45ms 58.55ms 8.97ms 10.81ms
iPhone 4 + Safari 5.1 16.65ms 115.80ms 303.38ms 135.24ms 155.57ms
Nexus 7 + Chrome 33 9.26ms 142.02ms 234.97ms 56.27ms 53.96ms
Nexus 7 + Firefox 27.0 3.15ms 40.92ms 143.55ms 173.68ms 202.97ms
F-01F + Android標準ブラウザ 4.2 7.85ms 36.12ms 102.62ms 62.57ms 69.95ms
F-01F + Chrome 33 7.47ms 114.68ms 164.34ms 41.70ms 43.21ms
F-01F + Firefox 27.0 2.76ms 35.26ms 140.37ms 124.33ms 173.30ms
WiiU 9.66ms 276.96ms 352.23ms 84.89ms 80.74ms
3DS 261.86ms - - 2288.00ms 2328.40ms

v3.3.6時のNexus 7がタッチパネルのもっさり感は、viewportが実解像度よりかなり大きかったためでした。
Chromeは、この測定をしたときは前回測定の26とかと比べて遅くなっていました。最近は速度が復活したようです。
また、v3.4.0は正答判定速度が前回よりかなり遅くなってしまった。これはv3.4.1で修正しています。
posted by はっぱ at 02:41| Comment(9) | TrackBack(0) | プログラム

2013年01月21日

ブラウザspeed調査

かなり前のぱずぷれv3のスクリプトで測定したデータしか無かったので、
今回ぱずぷれv3のv3.3.6リリースと共に測定し直してみました。

MacBook Pro 13" Retina
ブラウザ正答判定全盤面描画リサイズ時描画
Safari 6.0.2 0.31ms 13.62ms 27.20ms
Chrome 26 canary 0.10ms 13.67ms 25.33ms
Firefox 18.0.0 0.18ms 5.81ms 22.06ms

MacBook Pro 13" Retina (Windows 8 on Parallels)
ブラウザ正答判定全盤面描画リサイズ時描画
IE10 0.13ms 39.95ms 39.19ms
Opera 12.12 0.22ms 6.68ms 19.99ms
Firefox 18.0.0 (比較用) 0.19ms 6.38ms 25.55ms

4年前の自作PC (Core 2 Duo E8400 + Radeon5770 + Windows 7)
ブラウザ正答判定全盤面描画リサイズ時描画
IE9 0.21ms 74.48ms 48.36ms
IE10 Release Preview 0.15ms 37.45ms 41.85ms
Firefox 18.0.1 0.24ms 5.22ms 22.53ms
Opera 11.60 0.25ms 6.65ms 19.02ms
Opera 12.12 0.26ms 6.42ms 19.61ms

6年前のLet's note (Core Solo + Windows XP)
ブラウザ正答判定全盤面描画リサイズ時描画
IE6 53.00ms 332.97ms 1661.33ms
IE6 + SilverLight 52.00ms 235.97ms 592.00ms
IE8 23.61ms 429.33ms 904.83ms
IE8 + SilverLight 24.24ms 77.80ms 238.77ms
Firefox 3.6.28 2.24ms 28.48ms 161.32ms
Firefox 18.0.1 0.80ms 16.89ms 70.02ms
Chrome 24 0.42ms 34.08ms 74.63ms
Safari 5.1.7 1.25ms 20.83ms 62.07ms
Opera 9.64 10.19ms 48.64ms 145.83ms
Opera 10.62 0.86ms 21.31ms 64.08ms
Opera 12.12 0.85ms 19.95ms 61.93ms

タブレットその他
ブラウザ正答判定全盤面描画リサイズ時描画
iPad3 + Safari 5.1 2.39ms 42.43ms 122.52ms
iPhone 4 + Safari 5.1 4.40ms 107.27ms 323.23ms
Nexus 7 + Chrome 18 0.72ms 67.99ms 154.28ms
Nexus 7 + Firefox 17.0.0 1.51ms 60.59ms 207.71ms
Nexus 7 + Firefox 18.0.0 1.25ms 76.59ms 230.11ms
F-05D + Android標準ブラウザ 4.0 1.18ms 34.50ms 124.24ms
F-05D + Chrome 18 0.77ms 65.23ms 152.60ms
WiiU 3.78ms 45.71ms 130.18ms
3DS 141.65ms 2791.00ms 2592.00ms

感想文

  • IE6とIE8レベルだとかなり動作がもっさりになる
  • 数字には出てないけど、Nexus 7がタッチパネルが妙にもっさりしている気がする
  • スマホのF-05D(ARROW X LTE)はそんなにもっさりしてない感覚なので、機器の作りの影響?
  • それ以外は特に影響のない範囲になっていると思います、昔のPCでも速い方のブラウザ使ってほしいですね。
  • IE9, 10は、特にIE9はSVGをappendChildするよりしないほうが遅いのはいったいどういうことなの。。
  • 描画をSVGじゃなくてcanvasにしたら、Chrome/Safari/IE9,10速くなる、Operaまあまあ速くなる、Firefox遅くなる、という感じになります。
  • 3DSはネタ、というかエラーはしないけど動作は全く実用的ではないです。しかもtouchイベント使えなくて、タッチパネルを長押し後動かすとmousemoveもとれるようになるとか。
  • 逆にWiiUだとtouchイベントもとれるし、速度的にも普通に動きます。CPU弱めかな?という印象はありますが。
posted by はっぱ at 01:49| Comment(21) | TrackBack(0) | プログラム

touchイベントとmouseイベントが複合したときのメモ

touchイベントとmouseイベントの絡みについて調べたのでメモ。

タブレット(Nexus 7)について

タッチパネルを押した時 -> touchstartイベントが発生する
タッチパネルを押して指を動かした時 -> touchmoveイベントが発生する
タッチパネルを離した時 -> touchendイベントが発生する。event.touchesには位置情報が無いのでevet.changedTouchesで取得する

タッチパネルを押してすぐ離した時
 -> 場合によってはtouchend後に続いてmousemove, mousedown, mouse up, clickイベントがこの順に発生する
   touchstartイベント時にevent.preventDefault()していたら発生しない


マウスを繋いでボタンを押した時 -> touchstartイベントが発生する
マウスを動かした時 -> mousemoveイベントが発生する
マウスのボタンを離した時 -> touchendイベントが発生する

IE10のポインターイベントについて

MSPointerDown, MSPointerMove, MSPointerUpイベントはmouseイベントとほぼ同じ。
MicrosoftのページやW3Cの仕様にはevent.pageXとか書いていないけど、いちおうeventオブジェクトへは渡してくれる。
posted by はっぱ at 01:28| Comment(12) | TrackBack(0) | プログラム

2011年12月22日

Mercurialのshare拡張で共有リポジトリを使う

このエントリは、Mercurial Advent Calendarの22日目です。

@sabo2と申します。勉強会等には一回も出たことがないので、ほとんどの方に初めてお目にかかると思います。
今回はよろしくお願いいたします。

share拡張の使い方

今回は、私は結構使っているのに日本語のblogの記事とかでは見かけたことがない、share拡張について書かせていただきます。

share拡張とは、複数の作業フォルダから一つのリポジトリの履歴を参照・更新できるようにする拡張機能です。
この拡張はMercurial 1.3以上では標準で添付されていますので、~/.hgrcにshare=と書いておくと有効化されます。 ShareExtension - Mercurial
それでは、早速使ってみましょう。

まず、共有元となるリポジトリを作ります。
saboc:work2 sabo2$ mkdir foo
saboc:work2 sabo2$ cd foo
saboc:foo sabo2$ hg init
saboc:foo sabo2$ echo foo > foo
saboc:foo sabo2$ hg commit -A -m"foo first commit"
foo を追加登録中
saboc:foo sabo2$ echo foo2 > foo
saboc:foo sabo2$ hg commit -m"foo second commit"
saboc:foo sabo2$ hg glog --style compact
@  1[tip]   ec224eaf7180   2011-12-22 04:45 +0900   sabo2
|    foo second commit
|
o  0   4896a14915db   2011-12-22 04:45 +0900   sabo2
     foo first commit
ベースとなる履歴を作成しました。ここで、早速shareコマンドで履歴を共有する作業フォルダを作成します、
コマンドの形式はcloneとほぼ同じですが、オプションは--noupdate/-Uだけのようです。
saboc:foo sabo2$ cd ..
saboc:work2 sabo2$ hg share foo bar
作業領域の更新中
ファイル状態: 更新数 1、 マージ数 0、 削除数 0、 衝突未解消数 0
saboc:work2 sabo2$ cd bar
saboc:bar sabo2$ hg glog --style compact
@  1[tip]   ec224eaf7180   2011-12-22 04:45 +0900   sabo2
|    foo second commit
|
o  0   4896a14915db   2011-12-22 04:45 +0900   sabo2
     foo first commit

履歴を共有する作業フォルダができました。なお、このフォルダにも.hgフォルダは存在していて、 中のメタデータにsharedであるという印が付けられています。

さて、早速こちらの作業フォルダでコミットしてみましょう。
saboc:bar sabo2$ echo bar > bar
saboc:bar sabo2$ hg commit -A -m"bar first commit"
bar を追加登録中
saboc:bar sabo2$ hg glog --style compact
@  2[tip]   9b08ed533683   2011-12-22 04:48 +0900   sabo2
|    bar first commit
|
o  1   ec224eaf7180   2011-12-22 04:45 +0900   sabo2
|    foo second commit
|
o  0   4896a14915db   2011-12-22 04:45 +0900   sabo2
     foo first commit
コミットできました。ここで、元の作業フォルダに戻ってログを確認してみましょう。
saboc:bar sabo2$ cd ../foo
saboc:foo sabo2$ hg glog --style compact
o  2[tip]   9b08ed533683   2011-12-22 04:48 +0900   sabo2
|    bar first commit
|
@  1   ec224eaf7180   2011-12-22 04:45 +0900   sabo2
|    foo second commit
|
o  0   4896a14915db   2011-12-22 04:45 +0900   sabo2
     foo first commit

元の作業フォルダに戻っても反映されています。このようにして、一つの履歴に対して複数の作業フォルダから参照・更新が可能になりました。 さらに、履歴は同じでもparent revisionが異なっていることが確認できます。

基本的なshare拡張についての説明は以上になります。
共有リポジトリから切り離したくなったとき

Mercurial2.0で、share拡張の中にunshareコマンドというのが追加されました。 このコマンドをどこかの作業フォルダ内で使用すると、共有元の履歴を自分の.hgフォルダへコピーして、履歴は自分のところを参照するように戻ります。 その後は、通常のMercurialのリポジトリとして使用できます。

なお、pathとかは特に設定されないので、hgrcにマニュアルで追加した方がいいでしょう。
共有される履歴の範囲

.hgフォルダをのぞいたことがある方だとわかると思うのですが、この作業フォルダは、'store'フォルダのみが共有されます。 ですので、localtag, bookmark, mqのパッチ等は共有されません。
わかっていればmqのパッチを2系統つけられたりして便利(ShareExtensionのページでは非推奨扱い)なのですが、次に書いた問題があります。

履歴改変は要注意

share拡張にはShareExtensionのページにもありますが、注意点がいろいろ書いてあります。 注意点の要点は"履歴がなくなったら他の作業フォルダがおかしくなるかもしれない"ということにつきます。

さて、履歴が削除されたときにどうなるかを実際にみてみます。 先ほどのfooリポジトリから、rev:2を削除してみます。
saboc:work2 sabo2$ cd foo
saboc:foo sabo2$ hg strip 2
バックアップのバンドルを /Users/sabo2/work2/foo/.hg/strip-backup/9b08ed533683-backup.hg に保存
saboc:foo sabo2$ cd ../bar
saboc:bar sabo2$ hg glog --style compact
警告: 作業領域の親 '9b08ed533683' が未知のリビジョンです!
o  1[tip]   ec224eaf7180   2011-12-22 04:45 +0900   sabo2
|    foo second commit
|
o  0   4896a14915db   2011-12-22 04:45 +0900   sabo2
     foo first commit

親が未知のリビジョンです、と出てきました。作業フォルダbarの親は2だったので、 それが削除されて親がいなくなってしまいました。

いちおうupdateとかはできるのですが、ShareExtensionのページには こうなってしまった時の回避手段として、debugsetparentというコマンドが記載されています。
このコマンドはデバッグ用のコマンドで、無理矢理現在の作業フォルダの親を指定してしまうコマンドです。
ただ、差分があるはずなのにないと表示されてしまったりの不都合が起きる可能性があります。 昨日久しぶりにそういう状況に陥ってしまいました。。

mqやstripやrebaseなどの履歴改変機能を使うな、と書いてあるのはこうなる恐れがあるからのようです。
なお、ハッシュ値が変わるとダメなので、qrefreshとかhisteditで中身が変わるのもアウトです。

sharedな作業フォルダの.hgの中身
通常のリポジトリと、sharedの.hgフォルダに入っているデータの違いは、以下のようになっています。
  • storeフォルダがない
  • requiresファイルに"shared"という行が増えている
  • sharedpathファイルが増えている ※storeの参照先が絶対パスで記載されている
saboc:bar sabo2$ cat .hg/sharedpath
/Users/sabo2/work2/foo/.hg
なお、勝手にこのsharedpathの中身を相対パスにかえても動作します。
windowsでTortoiseHgをつかってsharedな作業フォルダを作成すると、ここにwindowsの絶対パスが入っています。
ただ、これをcygwinから参照しようと思ったら、こんなことを言われてしまいます。
中止: .hg/sharedpath の参照先 /cygdrive/c/Users/sabo2/work2/C:\Users\sabo2\work2\foo\.hg は存在しません!
こうなった時相対パスにすると、cygwinおよびコマンドプロンプトで参照できるようになります。
ただこうすると、今度はTortoiseHgで開けなくなる(絶対パスでないとダメらしい)ようです。。
むりやりmqを使ってみる

履歴以外は各作業フォルダで固有なので、mqのパッチも別々にあてることができます。 この時どうなるかを見てみます。

まず、一つの作業フォルダでパッチを作ります。
saboc:bar sabo2$ echo bar2 > bar
saboc:bar sabo2$ hg qnew BAR2 -m"bar second commit"
saboc:bar sabo2$ echo bar3 > bar
saboc:bar sabo2$ hg qnew BAR3 -m"bar third commit"
saboc:bar sabo2$ hg glog --style compact
@  4[BAR3,qtip,tip]   ba125581993b   2011-12-22 05:30 +0900   sabo2
|    bar third commit
|
o  3[BAR2,qbase]   4668026d9c78   2011-12-22 05:30 +0900   sabo2
|    bar second commit
|
o  2[qparent]   9b08ed533683   2011-12-22 04:48 +0900   sabo2
|    bar first commit
|
o  1   ec224eaf7180   2011-12-22 04:45 +0900   sabo2
|    foo second commit
|
o  0   4896a14915db   2011-12-22 04:45 +0900   sabo2
     foo first commit
リビジョン3,4がパッチ管理下におかれています。
これを別フォルダから見てみます。
saboc:bar sabo2$ cd ../foo
saboc:foo sabo2$ hg glog --style compact
o  4[tip]   ba125581993b   2011-12-22 05:30 +0900   sabo2
|    bar third commit
|
o  3   4668026d9c78   2011-12-22 05:30 +0900   sabo2
|    bar second commit
|
o  2   9b08ed533683   2011-12-22 04:48 +0900   sabo2
|    bar first commit
|
@  1   ec224eaf7180   2011-12-22 04:45 +0900   sabo2
|    foo second commit
|
o  0   4896a14915db   2011-12-22 04:45 +0900   sabo2
     foo first commit
一切パッチ管理下におかれていないかのようなLogが出力されました。
この作業フォルダでもパッチをあててみます。
saboc:foo sabo2$ hg up -r 3
ファイル状態: 更新数 1、 マージ数 0、 削除数 0、 衝突未解消数 0
saboc:foo sabo2$ echo foo3 > foo
saboc:foo sabo2$ hg qnew FOO3 -m"foo third commit"
saboc:foo sabo2$ hg glog --style compact
@  5[FOO3,qbase,qtip,tip]:3   bf0e83041fb9   2011-12-22 05:35 +0900   sabo2
|    foo third commit
|
| o  4   ba125581993b   2011-12-22 05:30 +0900   sabo2
|/     bar third commit
|
o  3[qparent]   4668026d9c78   2011-12-22 05:30 +0900   sabo2
|    bar second commit
|
o  2   9b08ed533683   2011-12-22 04:48 +0900   sabo2
|    bar first commit
|
o  1   ec224eaf7180   2011-12-22 04:45 +0900   sabo2
|    foo second commit
|
o  0   4896a14915db   2011-12-22 04:45 +0900   sabo2
     foo first commit
この状態で、さらに元のフォルダに戻ってどのような履歴になっているのか確認してみます。
saboc:foo sabo2$ cd ../bar
saboc:bar sabo2$ hg glog --style compact
o  5[tip]:3   bf0e83041fb9   2011-12-22 05:35 +0900   sabo2
|    foo third commit
|
| @  4[BAR3,qtip]   ba125581993b   2011-12-22 05:30 +0900   sabo2
|/     bar third commit
|
o  3[BAR2,qbase]   4668026d9c78   2011-12-22 05:30 +0900   sabo2
|    bar second commit
|
o  2[qparent]   9b08ed533683   2011-12-22 04:48 +0900   sabo2
|    bar first commit
|
o  1   ec224eaf7180   2011-12-22 04:45 +0900   sabo2
|    foo second commit
|
o  0   4896a14915db   2011-12-22 04:45 +0900   sabo2
     foo first commit
...パッチの途中から通常のリビジョンが分岐している、かなり怪しいグラフが出てきました。
ちなみにこの状態をTortoiseHgで見てみると、以下のようになります。
ayashii.png
なお、この状態でリビジョン4はqpopできますが、リビジョン3はできません。
また、リビジョン3がqtopの時は、通常リビジョン(に見える)子孫チェンジセットが別にあってもqpushできます。
saboc:bar sabo2$ hg qpop
BAR3 の適用解除
適用中の最上位パッチは BAR2 です
saboc:bar sabo2$ hg qpop
中止: 管理対象外のリビジョンが解除対象に指定されました
saboc:bar sabo2$ hg glog --style compact
o  4[tip]   bf0e83041fb9   2011-12-22 05:35 +0900   sabo2
|    foo third commit
|
@  3[BAR2,qbase,qtip]   4668026d9c78   2011-12-22 05:30 +0900   sabo2
|    bar second commit
|
o  2[qparent]   9b08ed533683   2011-12-22 04:48 +0900   sabo2
|    bar first commit
|
o  1   ec224eaf7180   2011-12-22 04:45 +0900   sabo2
|    foo second commit
|
o  0   4896a14915db   2011-12-22 04:45 +0900   sabo2
     foo first commit

saboc:bar sabo2$ hg qpush
(作業領域の親リビジョンはヘッドではありません)
BAR3 を適用中
適用中の最上位パッチは BAR3 です
メリットとデメリット

私は通常仕事のリポジトリがCVSになってしまっているorzために勝手mercurial管理しているのですが、 チームの変更についていく方の作業フォルダと、自分の作業を行う作業フォルダを分離できるので アップデートの手間が省けてかなり便利です。
それ以外では、通常は軽い変更を行うときにいちいちcloneするよりは気軽という点、 またstoreフォルダが共有なので、リポジトリのサイズがかなり軽くなるというメリットがあります。

デメリットは履歴改変機能が使いづらくなることでしょう。特にrebaseをやった時に結構な確率で 地雷を踏んでしまう気がしています。。

あとがき

ここまでお読みいただきありがとうございました。
履歴改変機能、という観点から言うとMercurial2.1で入るphases/states StatesPlan - Mercurial (旧LiquidHg)を皮切りにいくつか提案されているMutableHgでどうなるのかが、share拡張機能の観点から言うと不安です。

Mercurial Advent Calendarは、他に参加者がいないようならば、 明日からは神に戻りまして@troterさんになります。よろしくお願いいたします。

タグ:mercurial
posted by はっぱ at 06:26| Comment(9) | TrackBack(0) | プログラム

2010年05月25日

かっこいいメニューを目指して

20100525015911.png

CSS3 Dropdown Menu by Web Designer Wall
JavaScriptを使わず、CSS3で作るクールな多段メニュー | エンタープライズ | マイコミジャーナル
上のような記事を見ていて、現在JavaScriptを使ってなんとか表示しているぱずぷれv3のメニューを、
CSS3だけでかっこよく表示できないかなぁと思って作ってみました。
最新のIE以外のブラウザだと、だいたいこのような表示になります。IE9は確認できてません。。
なお、クリックしても特に何も起こりません。
 
はっぱメニュー (IE7切り捨て版)
はっぱメニュー IE7妥協版
はっぱメニュー button要素版 ※li要素をbutton要素にしただけ。おまけ。

以下、いろいろ箇条書きで。
 
対応ブラウザなどについて

  • Firefox 3.5以上, Safari 4, Google Chrome 4.1, Opera 10.5xではグラデーション、角丸、影付きで表示されます

  • Safari 3.2はグラデーション以外の角丸、影には対応しています

  • Firefox 2.0以上は角丸のみに対応しています(ただし、Firefox2.0のIE7切り捨て版は不安定です)

  • Opera 9.6x以上, Internet Explorer 8.0ではメニュー自体は表示されますが上記の効果はありません

  • Internet Explorer 7.0はIE8等と同等のレンダリングになるような妥協版で。

  • IE6?なにそれ?おいしいの?腐ってるの?


工夫した点

  • TYPE1とTYPE2の違いはHTML上で5行(menu要素の段数が1つ増えた)、CSSでも7項目です

  • Firefox 3.5+, Opera 10.5xは(-moz-)box-shadowのinset指定を使ってグラデーションのように見せてます

  • Safariはinsetが使用できず、外側の影まで消えてしまうので、-webkit-linear-gradientを使用してメニュー内の影を表示しています

  • Google Chrome 4.1ではinsetは使用できますが、border-radiusの部分に影の色がついて表示が変なので-webkit-linear-gradientを使用しています

  • menuの一番上のcaptionは、:before擬似クラスでlabel属性を表示し、text-shadowプロパティを使って周りに黒色の影を表示しています

  • 角丸はmenu要素とli要素のborder-radiusの組み合わせで表現しています

  • 下部にメニューがあることを示す->は、li:before擬似クラス+float:rightで表現しています

  • menu要素へのmin-width指定とspan要素のwhite-space:nowrap;を組み合わせることで、横幅が可変になっています


IE7妥協版の変更点・制限事項

  • menuのタイトルを:before擬似クラスではなく1要素目にspanタグを入れることで対応しています

  • HTML4.01ではmenuタグの子要素はliタグのみ許可、HTML5はmenu要素直下のspan要素は表示されないらしいので、マークアップ的にイマイチです

  • :first-childで指定していた角丸は:nth-child(2)で設定しています

  • hr要素で指定していたセパレータは、直後のli要素のスタイルにmargin-topプロパティを指定することで何とかしています

  • 下部にメニューがあることを示す->は、:before擬似クラスが使用できないので直接書いてます

  • menuがかぶった場合、IE7ではli要素が下部メニューのmenuの上にレンダリングされる?ので、横幅に大きな値を指定して固定幅にし、重ならないようにしています

  • 全体的に、マークアップのお行儀が悪いです

  • IE6


将来への課題

  • HTML5のmenu要素は実装がさっぱりなので、キャッチアップしていきたい

  • menu要素直下の要素がすべてli要素だが、command要素や見た目がボタンじゃないbutton要素が実装されたら変更したい

  • グラデーションとして(-moz-)box-shadowを使っているのはイマイチ?

  • ポップアップ後だけでなく、最初に表示されているメニューもやる気出したほうがいいと思う

posted by はっぱ at 02:13| Comment(10) | TrackBack(0) | プログラム

2010年03月19日

ボールが300個跳ねるのを作ってみた

ちょっとパズルとは関係ないのですが、暇だったので、
数日前にこないだボールを300個跳ねさせるのを作ってみたんです。
http://icecream.15.kg/hima/ball.html
 
で、これで描画関係の処理スピード計れそうなので見てみました。測定条件は例によってこんな感じ。
PC:2006年に買ったLet's note (CF-W5) URL ※2008年に組んだ自作PCの1/3の性能。
canvas -> 全画面毎回再描画。
SVG -> circle要素を初めに出力して、rx,ryプロパティだけ変更する
(Gradはグラデーション)

ボール300個のアニメーション時のFPS
ブラウザSilverlightVML
丸のみ丸+borderGradGrad+border 丸のみ丸+borderGradGrad+border
InternetExplorer 8.0 8.1 4.4 2.9 2.2 2.0 0.97 0.84 0.51
ブラウザcanvasSVG
丸のみ丸+borderGradGrad+border 丸のみ丸+borderGradGrad+border
SeaMonkey 1.1.18 9.2 3.2 2.6 1.8 3.4 1.7 1.3 0.88
Firefox 3.0.18 10.7 3.3 6.9 2.8 3.9 1.6 3.3 1.5
Firefox 3.5.8 12.6 3.8 7.5 3.0 4.6 2.8 3.7 2.4
Firefox 3.6 16.9 4.5 9.2 3.6 5.5 3.4 4.0 2.8
Firefox 3.7a3pre 17.2 4.3 10.3 3.8 5.3 3.3 4.8 2.9
Safari 3.2.3 N/A N/A N/A N/A (6.4) (4.9) (5.0) (3.9)
Safari 4.0.5 26.1 14.4 10.0 7.9 12.8 7.2 6.7 4.6
GoogleChrome 4.0.249.89 32.0 13.4 4.0 3.4 12.7 3.9 6.2 2.1
GoogleChrome 5.0.342.2 Dev 32.0 14.4 4.0 3.5 14.6 4.3 5.9 2.2
Opera 9.64 12.3 4.9 7.5 3.9 6.9 3.7 4.5 2.8
Opera 10.10 11.6 7.8 7.8 6.4 11.4 7.4 6.0 4.9
Opera 10.50 32.6 16.2 15.7 9.7 15.1 8.8 6.9 5.3
※IE8はuuCanvas.js v2.0.2使用、SeaMonkeyはFirefox2.0の代わり
以下分かったことを箇条書きで
  1. 全体的にSVGよりcanvas全画面描画の方が速い。SVGのほうが圧倒的に処理量少ないはずなので、個人的にはかなり意外
  2. Safari3.2.3のcanvas描画がエラーになっちゃう上、SVG描画はものすごく酷く乱れる
  3. Safari4のSVG描画は改善されてるけど、それでもちょっと欠ける部分がある
  4. GoogleChromeはcanvasのグラデーション処理に弱いっぽく見える
  5. Firefoxはcanvasでボーダーとなる線を描くと性能が落ちる
  6. IE9はスクリプト改造してみても落ちちゃうので測定できませんでした。
  7. IE6はめんどくさいので測定しませんでした。
  8. 数字が多すぎるのでグラフにすべきだったと思った
posted by はっぱ at 04:51| Comment(14) | TrackBack(0) | プログラム

2009年12月22日

新機能の追加に向けて

さて、最近Webブラウザに付け加わっている新機能を見ているのですが、結構いろいろなものがありますね。
ローカルにデータを保持できる - Web Storage, Web DataBase

昔っから、JavaScriptを利用して訪問回数とかを残すのに、cookieっていうのが使われてました。
このcookieって、データが4KBまでしか保存できなかったので、
例えばぱずぷれv3の盤面データとか残せなかったのですが、もっと保存できるようにしたやつ。
 
まず、localStorageっていうのがあって、localStorage[hogehoge]って書いてデータとか保持できる。
保持できるのは文字列だけで多次元配列とか出来ないけど、総容量は仕様にはないっぽい。
ただし、こういったものには珍しくIE8が対応していて、そのサイズが1ドメインあたり10MBなので
事実上そのあたりが上限ですかね。他にもFirefox3.5, Safari4は対応していて、
旧仕様ではFirefox2.0, Firefox3.0でも使える感じ。
 
次に、旧称Web DataBase、新名称Web SQL DataBaseっていうのがあって、
これはSQLiteというデータベースソフト(or同じ動作をするやつ)を直接叩いてデータを保存するやつ。
これはSafariがSafari3から先取り対応してたのですが、特定のソフトに依存する状況が嫌がられてて
MicroSoftと特にMozillaが実装しねぇ、と言ってる感じ。
 
その中間あたりな仕組みとしてIndexed DataBase APIっていうのがあって、
これにMicrosoftとOperaがノリノリっぽくて、Mozillaも実装しそうだけど、
まだ仕様書の内容が書き換わりまくってる状態だし、対応したブラウザが出来るのは当分先かなぁ。
 
何か今日W3Cのメールで「Microsoftの人だけど仕様文書案できたよ!」(by Microsoftの人)
「Operaだって手伝ったぞゴルァ」(by Operaの人)ってMailが公開されてました。
いや、全部そういうのって公開されてるんだけど何か可笑しかったので。。

ローカルファイルの読み込みだってさ - File API

こういった内容はHTML5っていう新しい仕様の関連で、今も議論されたりしている内容で、
結構期待されていて記事とかも結構あったりします。HTML5。APIは最近切り離されまくりだけど。
でも、そういうHTML5関連のAPI紹介の記事とかがあってもあまり紹介されていないような
マイナーな機能としてFile APIっていうのがあります。
 
ぼくも気づいたのつい最近だったんですが、
ユーザーがファイルボックスから入力したファイルの名称やサイズを取得できたり、
Firefoxではファイルの中身まで取得できちゃうんですよね。
旧仕様での実装がFirefox3.0以降、現在の仕様ではFirefox3.6beta4以降だけ対応しています。
 
つまり、Firefoxでは外部のcgiとかにアクセスしなくても「ファイルを開く」ことができる、というわけ。
これは僕にとってはけっこう嬉しい。まぁ、外部cgi介す実装を残すのは必要ですけど。
ただ、これは他のブラウザが将来対応するかどうかが不透明ですね。。
IEは将来やるかもしれない?という思わせぶりな態度をとっているらしいけど、、
 
で、ファイルを読み込めるなら書き込みはあるの?→ そりゃセキュリティ的にやばいだろ、、
と思っていたのですが実はまさにローカルファイルを書き込む
File Writer APIっていうのも作り始めてるみたいですね。今月仕様の原案出たばっかりですが。
これが出来たらファイルの読み書きに外部cgiのアクセスを介すのがいらなくなるのかも?
# でもうちのぱずぷれv3じゃなくて得する人いるのかなぁ。
 
ちなみにFile Writer APIはFile Readerと別の、デバイスAPIグループで議論されているみたい。
このデバイスAPIグループって最近出来たらしいのですが、Webカメラの入力画像をJavaScriptで処理したりとか、
テキストを入力したら音声が出力されるJavaScriptとか、なんかすごそうなことをやっていますね。。
posted by はっぱ at 02:26| Comment(20) | TrackBack(0) | プログラム

2009年04月21日

Silverlightからキー入力を受け取る

昨日の続きですが、なんとかSilverlightからキー入力を判別する方法が分かったので
ぱずぷれv3 uupaa-excanvas対応版をアップしました。
速さは昨日の通り(なぜかSilverlight使用時が5%くらい速くなってた)。
 
さて、SilverlightでJavaScirptを利用してキーイベントを取得する方法ですが、
やはりCanvasにキーを押す/離すに相当するKeyDown, KeuUpイベントが存在しているらしいです。
ただし、CanvasのSilverlightオブジェクトを取得しなけりゃいけない。
さて、それをやれるのはどこかというと、一つの回答はこんな感じ。
Canvasに対してcreateObject関数を使ってSilverlightから扱えるようにするのですが、
扱えるようになった時にonLoadイベントに設定された関数が呼ばれます。
この中でやるのがいちばん素直らしい。
function onLoadFunction(sender) {
  sender.AddEventListener("KeyDown", keydownFunction);
  sender.AddEventListener("KeyUp", keyupFunction);
}
 
Silverlight.createObject(
  (中略)
  {
    onLoad: onLoadFunction
  }
);
senderは、イベントが起こったオブジェクトを指します。
今回は、読み込みが終わった、というイベントなのでそのもの=ちょうど登録が終わったCanvasが入っていると。
後からつけるならば、AddEventListenerという関数でこんな感じに指定できるらしいですね。
 
それで、このkeydownFunction. keyupFunction関数がどう呼び出されるかというと、
keydownFunction : function(sender,keyEventArgs){
  var e = {};
  e.keyCode = keyEventArgs.platformKeyCode;
  e.shiftKey = keyEventArgs.shift;
  e.ctrlKey = keyEventArgs.ctrl;
 
  onKeyDownFunction(e);
}
今回はsenderはいらないので、2つめの引数のkeyEventArgsばっかり見ています。
そのkeyEventArgsにキーの情報が入っていて、keyEventArgs.Keyってやつもあります。
でも、なぜplatformKeyCodeっていうものを見ているかというと、、
  keyEventArgs.Key         ・・・・Silverlightで決まっている値(どのブラウザでも共通)
  keyEventArgs.platformKeyCode ・・・・JavaScriptのonkeydownイベントとかの値と同じ(ブラウザによって異なる)
 
確かにいつでも同じなのはいいのですが、今回はもともとクロスブラウザで作成済みなワケで、
既存のコードと親和性が高いplatformKeyCodeプロパティを使うのが良いというわけですね。
なお、onKeyDownFunction()関数は既存のやつと考えていて、どうせここ通るのIEだけだし
shiftKey, ctrlKeyも設定してやることで、既存の関数を丸々流用できる、というわけ。
 
なお、Silverlightオブジェクトにフォーカスがある時、
documentに設定していたonkeydown, onkeyupのイベントは反応してくれませんでしたが
なぜかonkeypressのイベントだけはそんなこと関係なく動作していました。
、、まさかkeydown/keyupの名前がかぶっていたから動作しなかった、、とか言いませんよね、、
 
しかしもともとVMLのほうでやる必要があったとはいえ、
uupaa-excanvas.jsの中のonLoad()関数をぱずぷれv3専用に魔改造しなきゃいけないのが玉に瑕。
そこでなんとか外部から取得する関数がないか、と調べようと思ったのですが
なぜかWeb上のmsdnライブラリが"コンテンツが存在しません"とか
言われてしまったので調査できず。今後の課題だなぁ。
posted by はっぱ at 23:54| Comment(539) | TrackBack(0) | プログラム