私は@timdayに同意します。調査を「本物の」ものに偏らせる必要があります。コメントで示唆したように、デスクトップまたはブラウザーベースのアプリのどちらを選択するかについての話にしたいと思うかもしれません。
これはまさに私が今取り組んでいることです。私のクライアントには、現在Windowsデスクトップで実行されている視覚化アプリケーションがあります。彼らの典型的なシーンには、500,000の三角形、たくさんのテクスチャ、そして透明度があります。現在、ユーザーはビューアをインストールすることを嫌がっています。システム管理者がコンピュータにインストールするものを制御する企業環境で作業する傾向があります。また、何人かのユーザーは、視聴者がとにかく実行されないiPadで視覚化を実行することを好みます。したがって、私のクライアントは、WebGLがプラットフォームの問題を解決するかどうかを知りたがっています。WebGLを公式にサポートしているブラウザはまだなく、IEもiPadもいかなる種類のサポートも発表していないことを気にしないでください。
移動するターゲットを測定しているため、実行するベンチマークは比較的無意味であることに注意してください。ブラウザメーカーはWebGLの実装に懸命に取り組んでおり、ベータリリースを頻繁に更新しています。彼らはWebGLの実装に準拠して取り組んでいるだけでなく、ブラウザのセキュリティの問題と全体的なパイプラインフローについて心配する必要があります。 このビデオでは、いくつかの問題について説明しています（そして、何を調べるべきかについてのアイデアを提供します）。また、OSやグラフィックハードウェアによってパフォーマンスが異なる場合があります。
ご指摘のとおり、WebGLがグラフィックハードウェアで実行されると、デスクトップアプリと同じ速度で実行されるはずです。ベンチマークはそれを確認する必要があります。次に、ブラウザーを使用した結果としてパフォーマンスが低下する場所を測定する必要があります。私の感じでは、実行するJavascriptがそれほど多くないという理由だけで、Javascript自体はボトルネックではありません（そして最近はかなり高速です）。ただし、前述のビデオの最後で説明したように、Javascript-C ++バインディング、要求検証、フロー制御などで非効率が発生する可能性があります。一方、ブラウザメーカー（少なくともGoogle）は、これらの問題を解決するために懸命に取り組んでいます。
私が気づいたことの1つは、フレームレート/パフォーマンスの問題ではありません（現在のテストでは、30 fpsで500,000のテクスチャ三角形をレンダリングできます）が、フレームレートはあまり一貫していないようで、フレームはドロップされているようです時々。setInterval()疑わしいですが、これが比較的単純な方法に関係しているのか、Javascriptでアニメーションを実行しているのかはわかりません。（MozillaのmozRequestAnimationFrameは、これをより適切に処理する方法である可能性があります）。
上記のいずれかがあなたの論文にどれほど役立つかはわかりませんが、あなたには豊富なトピックがあり、単純なベンチマークを作成する以上のことを行う必要があるようです。おそらく、いくつかのベンチマークから始めて、ブラウザーとデスクトップのパフォーマンスを比較してから、ブラウザーとデスクトップのどちらかを決定するだけでなく、WebGLアプリを作成するためのベストプラクティスを検討する必要があります。
そこにもかなりの数のWebGLフレームワークがあります。私はカップルを試しましたが、非常に感銘を受けました。彼らから学ぶことはたくさんあります。興味や論文の要件によっては、これらのベンチマークにも興味があるかもしれません。
いずれにせよ、調査しようとしている種類の情報に飢えているWebGL採用者の大規模なコミュニティがあるのではないかと思います。