ブログを移転しました
さらにBlogを移転しました。はてなダイアリーのエントリーも取り込んでいます。
http://blog.taiyolab.com/
blogを移転しました
長らくお世話になったはてなダイアリーからblogspotへ移転することにしました。
新しいblogはこちらです。
http://taiyo-fujii.blogspot.com/
画像編集するHTML5デモ
HTML5 3DaysのHackathonでプロトタイプを作成したpbeditのオンラインデモンストレーションを公開した。
http://web.me.com/t_trace/pbedit/image_loader.html
並んでいるサムネイルをクリックすると編集画面へ移動し、RGBチャンネルのスケール編集が可能です。
動作環境はSafari 4.0(検証してないだけですが)。
ローカルファイルから実行するとクリップボード経由で編集する画像を読みこんで編集できます。
ローカル実行のために.zipで固めたファイルはgithubからどうぞ。
http://github.com/ttrace/pbdit/downloads
このデモンストレーションを作成するにあたっていくつかHTML5 3Daysで提案されていたことを試みました。
1. Web Workersを用いた非同期処理
2. Web Database / Storageを用いた保存
結論から言うと、いずれもパフォーマンスの面であきらめています。
Safariの現状のWeb Workersでは、Web Storageを用いることができないため、Workersへデータを渡す方法はonmessageとpostMessageを用いたメッセージングのみとなりますが、受け渡しできるのはstring(文字列)のみとなります。
canvasのPixelDataArrayを文字列に展開して1000x1000ピクセルの画像を受け渡しすることは、64bit Safariであっても4GBしかメモリを積んでいない環境ではオーバーヘッドが大きすぎて断念。
また、Database、Storage、いずれも1000x1000程度で30MB程度の容量を消費してしまい、数値列の変換にかかるコストが無視できないほど大きいものとなります。
Web Databaseを用いた処理は上記のソースコードにコメントアウトされたまま残っていますので、興味がある方はぜひ眺めてみてください。
CanvasやCSS3の描画速度、レスポンスはきわめて軽快であり、複雑なインターフェイス操作にも耐える。
重い処理の非同期化が課題ではあるけどWorkersへオブジェクトのままでデータを渡せるか、WorkersでopenDatabaseが実行できるようになると解決するだろうからそれまで待ちだなぁ。
pbtweet使ってると遅くなる
というエントリーを書いた。
http://pbtweet.blogspot.com/2009/09/slowness-with-using-pbtweet.html
はい、遅くなります。そりゃもうtwitterのオリジナルスクリプトもインターフェイスも数百tweets並ぶことしか考えてないんだから印刷すると10mに達するような自動更新なんて考えているわけがない。遅くなるポイントは2つ。
- 長いタイムラインができた後のタブ切り替え
- テキスト入力
1については1.5開発版の0070で対処した。どういう処理をしてるのか特に分析はしてないけどtwitterのオリジナルスクリプトはタブ切り替えるときにtweetをひとつひとつ触ってるんで、先手を打ってtimelineを丸ごと削除して空のtimelineオブジェクトを突っ込むことにした。
2も原因は同じなんだけど対処はちょっと面倒なことになりそう。テキスト入力を監視しているtwitterのオリジナルスクリプトはjQueryなんだが、同じオブジェクトでtweetも監視してるのか、tweetが増えるといきなり処理が重くなる。これを回避するにはオリジナルスクリプトがイベントをdispatchしているフォームを隠して代替インターフェイスを用意してやりゃいいんだけど、オリジナルスクリプトで提供してる機能を削る訳にも行かないから工数多そうなんだよね。というわけで、これは1.6以降。
自由に実装できる自前の入力フォームはもともと予定に入ってたんだけど、twitterがAjax化されてから重くなったから予定を巻き上げて作る必要が出てきてしまった。
pbtweet 開発版 1.5 0069
Operaサポートをちょっとやってみました。
http://pbtweet.blogspot.com/2009/09/pbtweet-dev-15-0069.html
動くってレベルならChromeとほぼコンパチなコードで動いちゃうことがわかったのはよかったな。
userscriptからのスコープがGreaseKit、Chrome/OperaとGreaseMonkeyでちょっとずつ違う。
とにかくヌルいのがSafariのGreaseKit。これは匿名関数にする必要すらないザル環境なんでグローバルな関数を直接userscriptに書いておけばどこからでも参照できる。
次がChromeとOperaで、user.js内で匿名関数の外側に書いた関数や変数は匿名関数の内側から参照できないからjsonpの処理をするような関数やオブジェクトをpbtweetでは外部スクリプトとして読み込んでいる。GreaseMonkeyはよくわからない。移植してるときに何か調べてとりあえず動く状態にしたけど普通の書き方ではスコープがなかったような気がする。
Opera版でちょっと困ってるのがCSS3のtransformationがないことかな。pbtweetではインターフェイスの表示、非表示などの制御にCSS3のtransformationを使ってる部分がいくつかあるんだけどこれがOperaで全く動いてないから設定パネルあたりは作り直し。それでもデバッガは動くしWebKitコードと将来的にはマージできそうなんで楽しんでやれてる。
64bit Safari用のGreaseKit
http://pbtweet.blogspot.com/2009/09/greasekit-for-64bit-safari.html
おなじみxddさんがGreaseKitのWebkit-plug-inを作りました。
http://d.hatena.ne.jp/xdd/20090829
激しく感謝。開発用に使わせていただきます。
基本的にAppleがinput-managerの瑕疵をつぶしたことは歓迎してるんだけどね。
userscriptはWeb標準にならんのかな?
dashmark
Safari 4で動かなくなったと思ってた[-]:dashmark がSnow Leopard用では動いてた。ちょっと懐かしい。そして、自分で言うのもなんなんだがものすごく使える。
http://pbtweet.blogspot.com/2009/08/dashmark.html