HTML5でビデオのリアルタイムヒストグラムを作ってみた - 風と宇宙とプログラム
デジカメを使っていると、撮影直後にヒストグラムを見て黒潰れや白飛びなどをチェックする癖がちょっとは身についたが、デジカメはもちろんのこと、今時のテレビにもヒストグラムをリアルタイムで表示する機能が付いているものもある。今回、HTML5のvideoタグの勉強がてら、再生中のビデオのヒストグラムをリアルタイムで表示するJavaScriptコードを書いてみた。 リアルタイムといってもJavaScriptのパフォーマンスに依存するので全部のフレームがヒストグラム表示されるとは限らない。計算自体は単純だが、画素数が多いとそれなりに負荷がかかる。ちなみに、某社のテレビでヒストグラム表示機能があるので確認したら、ゆったりとした動きだった。 HTML5のビデオからそのヒストグラムを生成する方法はとても簡単だ。まず、再生中のビデオのピクセル情報を取得するため、一旦、canvas上にdrawImage()でビ
Canvasのベンチマークテストを作って速度を比較してみた - 風と宇宙とプログラム
はじめに Canvasのパフォーマンスを測定するベンチマークプログラムはそこら中に転がっていますが、ほんの一部分の測定だったり、逆に中身が複雑過ぎたりと僕が希望するようなものが見当たらなかったので、自分で作って各ブラウザで測定してみました。 測定したブラウザのバージョンは以下です。 Chrome Firefox Safari Opera 9.0.570.1 dev 3.6.12 5.0.2 10.63 ベンチマーク 作成したベンチマークプログラムは単位時間で描画関数を何回繰り返して実行できるかという単純なものです。実行中に描画される絵のいくつかを載せておきます。 hlinebezierfill_arcfill_starsimage_scaleradial_gradient 以下に全測定項目の概要を記します。 hline ひたすら水平方向の直線を描きます。 vline 垂直方向の直線 lin
Canvasのイメージ拡大描画について比較してみた - 風と宇宙とプログラム
CanvasのdrawImage APIは下図のように、ソースイメージ中の任意の矩形領域をCanvas領域中の任意の大きさの矩形にマッピングできます。 context.drawImage(image, sx, sy, sw, sh, dx, dy, dw, dh) このAPIによって、イメージの部分領域の縦・横方向の拡大縮小が自由にできるようになっています。 今回は、この拡大機能がちょっと気になったので以下のブラウザの各バージョンで調べてみました。 Firefox Chrome Safari Opera 3.6.11 8.0.552.11 dev 5.0.2 10.63 調べたのは、下のような赤と青が１ピクセル毎に交互に描かれているイメージを拡大したときの補間の表現です。 このイメージを下記表のように拡大してみました。 5倍 10倍 20倍 40倍 80倍 160倍 320倍 640倍 1
HTML5 Canvasのブラウザによって異なる微妙な振る舞いについてまとめてみた。 - 風と宇宙とプログラム
はじめに CanvasはHTML5とは切り離された独立した仕様(HTML Canvas 2D Context)になっているようですが、現状のブラウザ上でのCanvasのについて、普段はあまり気にしない微妙な振る舞いについて調べた結果をまとめてみました。 調べたブラウザの各バージョンは以下の通りです。 Firefox Chrome Safari Opera 3.6.8 6.0.490.1 dev 5.0.1 10.61 線を描く (lineTo) ただの直線を描くだけのlineToですが、その単純なものにも、恐らく、多くの人が普段は気にしないような問題があります。それは座標値とアンチエリアスです。詳しく見る前に、実際の結果を示しましょう。下記のイメージ中に描かれている線は、いずれも線幅(lineWidth)が1の線です。 (左から、Firefox, Chrome, Safari, Opera
HTML5 Canvas のarcTo関数の実装が未だにorz - 風と宇宙とプログラム
２年近く前にCanvas APIの実装状況を網羅的に調査したことがありますが、ブラウザごとに実装がいろいろ異なっていていました。その中で一番目立ったのがarcTo関数の実装の違いです。改めて調べてみました。 ブラウザのバージョンは以下です。 Chrome Safari Opera Firefox 4.0.249.43 4.0.4(531.21.10) 10.10 3.5.7 IEはExplorerCanvas r3を見てみましたがarcToは実装されていませんでした。 テストケース 今回、新たに簡単なテストケースを作りました。左図のような絵を描画するものです。arcToだけを使って描画しています。ちょっとキモイ絵になってしまいした。 Chromeではこうなります まあまあですが、描かれるべき線と左目の点がありません。 左目の点がないのは、arcToの問題もありますが、さらに長さゼロの線に対
JavaScriptのパフォーマンスの違いから数値表現の違いを推定してみた - 風と宇宙とプログラム
はじめに JavaScriptの数値は仕様的には64bit倍精度のIEEE754に準拠というものですが、内部の実装では高速化のために必要に応じて32bit整数だったりdoubleだったりします。ブラウザによっては、その辺りの実装に違いがある筈で、それはパフォーマンスの違いとなって現れるのではないかと予想したので、それを測定してみました。 ベースラインの測定 そのためには、ベースラインをはじめに測定する必要があります。C言語でint32型、int64型、double型のパフォーマンスを測定します。C言語レベルでint型とdouble型のパフォーマンスの違いが観測されなければ、JavaScriptの内部の実装でそれらを区別して実装していても、外部からはその違いが観測されないでしょう。 下記の簡単な関数を実行したときの時間を計測しました。 void perf_int32(int n) { vol
JavaScriptのToNumberとparseInt/parseFloatの仕様と実装の違い - 風と宇宙とプログラム
ECMAScriptの規格書は非常に細部に至るまで細かく仕様が規定されていますが、１００％全て正しく実装している処理系は僕の知る限りありません。過去に広まってしまったソフトとの後方互換性を維持するため、あえて仕様にあわせていないのだろうというものもあります。ECMAScriptの規格と各ブラウザのScriptエンジンとの違いは、いずれ機会があればまとめたいと思っていますが、コーナーケース（いわゆる重箱の隅系）になると、膨大な量になります。 今回は、文字列を数値に変換する際に登場するToNumberとparseInt/parseFloatについて簡単に紹介します。ToNumberは規格書に登場する内部の実装関数であり、parseInt/parseFloatはご存知JavaScriptのグローバル関数です。 ToNumberの引数が文字列のとき、規格書ではその文字列の文法が厳密に規定されていて
JavaScriptで循環配列を文字列化したらどうなるか？ - 風と宇宙とプログラム
JavaScriptのオブジェクトは文字列化しても単に "[object Object]"と表示されるだけなのに、配列は文字列化すると "1,2,3,4" のようになる。便利なようであまり便利でもない。 var ary = [1,[2,[3,4]],5] var s = ary.toString(); // s は "1,2,3,4,5" 各要素も再帰的に文字列化してくれるが、構造が見えない。 では、配列が循環したらどうなるのか？ var ary = [1,2,3,4]; ary[2] = ary; var s = ary.toString(); 3番目の要素を自分自身で置き換えたので、循環構造になるので普通に文字列化してしまうと、 [1,2,[1,2,[1,2[......... のように無限長文字列になってしまう。 実際にブラウザで確認してみた。 Firefox, Safari, IE
JavaScriptで ""+x を文字列変換に使うのは気持ち悪い - 風と宇宙とプログラム
JavaScriptの本やブログなどで非常に良く見かけるのだが、数値などの文字列でないものを文字列に変換する方法として var s = "" + x; のように空文字との連結によって行っているが、私としてはちょっと気持ち悪さを感じる。もちろん、間違いではない。確かにxは文字列に変換される。+の左側が空文字でなく、何かの文字が書かれている場合には、普通にやることだ。空文字との連結に違和感がある。じゃ、どう書くかというと、 var s = String(x); と書く。なんか、タイプ数が増えるし面倒じゃん？という声が聞こえてきそうだが、Stringという引数を文字列に変換するという目的そのものの関数が定義されているのに、わざわざ + 演算子を使うことが気持ち悪いのである。しかも、+ 演算子という多層演算子を使うのでコードが読みにくい。さらに、上のような書き方があまりにも普及してしまっていて、S
JavaScriptの基本型とオブジェクト型のパフォーマンスの違い - 風と宇宙とプログラム
JavaScriptの数値や文字列などの基本型はオブジェクトではありませんが、あたかも対応するクラスのインスタンスオブジェクトであるかのようにメソッドをコールすることができます。例えば、下記のプログラムではv1とv2はどちらも"123.00"という同じ文字列になります。x1は123という基本型の数値であり、オブジェクトではありません。一方、x2はNumberのインスタンスオブジェクトです。どちらも、Number.prototype.toPrecisionというメソッドが実行されます。 var x1 = 123; var x2 = new Number(123); var v1 = x1.toPrecision(5); var v2 = v2.toPrecision(5); 今回の話は、この両者でパフォーマンスに違いはあるか、あるとしたらその理由は何か、ということです。 実際に確かめてみまし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
