ハードウェア特性に基づいた WebGL 高速化手法 WebGL fast method that is based on hardware characteristics

1. ハードウェア特性に基づいた
WebGL 高速化手法
WebGL fast method that is based
on hardware characteristics
2015/6/6 WebGL Meetup Tokyo #2
株式会社エクサ 安藤幸央
@yukio_andoh

2. WebGL Cheat Sheet
via. https://www.khronos.org/files/webgl/webgl-reference-card-1_0.pdf

3. SGI IRIS GL 1984∼, OpenGL 1992∼ VRML 1995∼ Canvas3D 2006∼ WebGL 2011∼

6. WebGLは、
ソフトウェア
というよりも、
ハードウェアを最大限
コントロールするため
のAPI

7. ２のべき乗サイズの
テクスチャの方が、
親和性が良いのも
そのせい

8. 速い？
遅い？
photo (cc) ph-stopphoto (cc) Will Richards

9. Google RAIL
100 ms
Response Animation Idle Load
16 ms 100 ms 1000 ms

10. Google RAIL
100 ms
Response Animation Idle Load
60 fps 50∼100
ms
1000 ms
fps : frame per second = フレームレート

11. via. https://paulbakaus.com/tutorials/performance/the-illusion-of-motion/

12. 遅くならない為には
ターゲットを絞る
パフォーマンス計画
を立てる
via. AKQA Winterlands

13. 初めは低いスペック
の端末に合わせる
高性能端末向けには
徐々にリッチな素材
を追加すれば良い
via. AKQA Winterlands

14. 何を重視するか、
基本ポリシーを検討
●美しさ？
●操作性？
●オブジェクト数？
●fps？
Photo (cc) Andrionni Ribo
cf. http://akirodic.com/p/jellyfish/

15. Pixar の Rendering の歴史
10 hour / frame
via. (C) Pixar

16. このハードウェアで
は、このくらい....
ベンチマークツールで
計ったり、単純サンプ
ルで計り比較する
（3DMark, GFXBench,
UnityBench 等）
via. (C) 3DMark

17. 透明、霧、照明、影表
現は高い負荷。
通常描画を透明にする
よりも、特別に考える
単なるブレンド描画で
十分な場合も...
via. http://blog.bonzaisoftware.com/stochastic-order-independent-transparency/#more-348

18. 手前から描くとカリ
ング（隠れている面
を描かない）が効く
ので速い。
ただし、PowerVR
系(iOS) は効かない
(Tile Based Deferred Renderer)
via. (C) imgtec

19. 後から加えるの
は容易だが、
後からチューニ
ングしたり削除
するのは難しい
photo (cc) Chris Martin

20. via. http://caniuse.com/

21. ブラウザ間の主な差
分はJavaScript部分
Chrome:V8
Safari: Nitro
Firefox: asm.js可
IE11: WebGL0.93
(全命令には未対応)
https://kripken.github.io/ammo.js/examples/new/ammo.html

22. 闇雲にチューニング
せずに、どこが遅い
のか見極める
パレートの80:20
の法則
photo (cc) Will Richards

23. JavaScript
CSS
http(img)
Network
WebGL

24. Page Speed
Insights
https://
developers.google.com/
speed/pagespeed/
画像の最適化や、サーバー
側の設定の不備など、まず
は JavaScript 周辺の遅い
箇所を発見できる

25. WebGL Inspector
http://benvanik.github.io/
WebGL-Inspector/
動作中の命令群のスナップ
ショットを取得し、
OpenGLの命令が無駄に重
複している箇所を見つける
ことができる。発見したら
ループ外へ移動するなど、
命令配置場所を検討できる

26. fps表示
chrome://flags fps
stats.js を取り込んでおく
方法もあり https://
github.com/mrdoob/
stats.js
機能追加ごとに速度を体感

27. via. http://daureg.free.fr/ta_webit/3d_pipeline.jpg
あらゆる箇所が遅くなる要因に....
CPUの限界、頂点の限界、ピクセルの限界

28. 何かの描画要素を
ON/OFF して何が
負荷なのか、何が関
係無いかを見いだす
テクスチャ有無、
ポリゴン数半分とか

29. 描画画面を 1/2 や
1/4 に小さくして
みる。
遅さが変わらないの
であれば、CPU/
JavaScript 側の
負荷が多い

30. 早すぎる最適化
は諸悪の根源で
ある
ドナルド・クヌース
（アルゴリズムの大家。アートオブコ
ンピュータプログラミングの作者）
photo (cc) Will Richards
トニー・ホーア説もあり

31. CPU GPU

32. 1+1
1+1
1+1
1+1
1+1
1+1
1+1
1+1
1+1, 1+1, 1+1, 1+1, 1+1, 1+1
CPU GPU

33. CPU GPU

34. JavaScript WebGL

35. CPU GPU
Unified Memory の場合を除く

36. WebGL は、
ステートマシン
一度設定した状
態は保持される
photo (cc) Eric Lubbers

37. 何度も同じ設定
をするのは無駄
設定を切り替え
るのは高負荷
photo (cc) Eric Lubbers

38. これらをふまえて...
高速WebGL
20の法則

39. #01
バラバラのポリゴンよ
りも、まとめたポリゴ
ンで扱う。
drawCallの回数を少な
く。THREE.js だと
GeometryUtils.merge()
ただし、妄信せず、コ
ンテンツ表現とのバラ
ンスが重要

40. #02
頂点データの再利用
drawElements() を使っ
た
indexed Polygon 指定
でできるだけデータ数
を少なく

41. #03
縮退三角形
Degenerate triangle
面積がゼロの三角形を
表現して、離れたポリ
ゴン同士を連続したも
のとして扱う

42. #04
同じことするにも、
複数の方法があり、速
い方法と遅い方法があ
る。
バイト配列の指定や
RGB順の違いなど
gl.bindTexture(gl.TEXTURE_2D, tex1024);
gl.texSubImage2D(gl.TEXTURE_2D, 0, 0,
0, gl.RGBA, gl.UNSIGNED_BYTE, img1024);

43. #05
必要の無い OpenGL命
令を何度も呼ばない
OpenGLはステートマシ
ンなので重複呼び出し
は高負荷。
パラメータの ON/OFF
をチェック。両面描
画？片面？フォグい
る？毎回クリア？

44. #06
ループの回数の多いと
ころ、負荷の多そうな
ところに気を配る
ループ内をよりシンプ
ルに、ループ外で良い
ことは、事前計算。
簡単に試すには、空
ループに書き換える等

45. #07
CPU、JavaScript で計
算しているが、
GPU側で出来そうなこ
とを肩代わりしてもら
う。事前計算しておく
特に同時並列で実行可
能な、それほど精度が
必要でないもの

46. #08
型付き配列を活用
Float32Array() が
座標値の配列にも色値
もマトリックス表現も
調度いい。適度な精度
trianglePositions = new
Float32Array([
// X, Y, Z,
-0.5, -0.25, 0.0,
0.5, -0.25, 0.0,
0.0, 0.559016994, 0.0]);

47. #09
テクスチャは一番資源
を食う。小さくて荒く
ても比較しないと実は
あまり気付かない。
よく使うテクスチャは
できるだけ始めの段階
でロードしてバインド
しておく。あとは切り
替えて使うだけ

48. #10
JPEG, PNG自身を圧縮
展開する時間もあるの
で、ハードウェアが対
応しているテクスチャ
圧縮フォーマットが一
番いい（要拡張命令）
実はネット上をやり取
りするのが一番遅い
（PNG圧縮、8bit index）
http://toji.github.io/texture-tester/

49. PowerVR PVRTC
via. http://wiki.sparrow-framework.org/manual/pvr_textures

50. #11
テクスチャのロードと
バインドは大きな負荷
テクスチャアトラスで
まとめる。
使う時に UV 指定をう
まくずらして使う
(C) Minecraft

51. #12
ミップマップを活用。
テクスチャがバインド
されたままで、最適サ
イズを切り替えてうの
で一番都合がいい。
遠くにあるオブジェク
トは描画面積も小さい
ので、小さいテクス
チャで十分。

52. #13
LOD活用
広い空間や、
広い領域を扱う場合
は、Level of Detail がと
ても効果あり。
視点から近い時は細か
く、遠い時は荒く

53. #14
read系の命令を描画
ループ中で使わない。
コンテキストスイッチ
ングにとても負荷がか
かる。設定値を read()
したり、ピクセル値を
read() したりがとても
遅い

54. #15
スマートフォン向けに
は、常に最大性能が良
いわけではない。
バッテリー消費とのバ
ランスを考慮する
3G/LTEは最初の立ち上
がりが遅いので、なる
べくまとめてやり取り

55. #16
エラーチェック用や、
デバッグ用のコードを
綺麗に取り除く。
笑うかもしれないが、
以外と盲点。
最初から仕組みを準備
しておく
エラーの発生を直すと
速くなる時もあり

56. #17
Retina なら 2倍拡大表
示でも十分？！

57. #18
カラースクリプティン
グ、ストーリーテリン
グも重要
雰囲気や、気分で速度
に関する感覚もだいぶ
変わる

58. #19
使えるからといって限
界値まで使わない
出来るだけ少なく
http://webglreport.com/

59. #20
利用機材を最適な環境
設定にしよう。
特にノートパソコン、
モバイル機器は、バッ
テリー温存のために
色々と遅くなる
GPUが切り替わる機種

60. まとめ
ハードウェアの性質や仕組みを理解し、最大限に生かす
適切な量と適切な表現で、無駄なことはしない
できるだけまとめて、場合によっては、できるだけ分割して
WebGL以外のネットやJavaScriptが遅くはないですか？
適切なチューニングには、適切プロファイリングが重要
選択と集中。ループの中を速くするのが一番効果あり

61. スマートなデータ
を使う
つまらないコード
を書くのだ
ロブ・パイク
（UNIX、Go言語の作者の一人）
photo (cc) Will Richards

62. WebGL は
インタラクティブ
な上に、動画より
も小さいよね！
Mr. doob
（Three.js の開発者）
photo (cc) ricardo cabello

63. おまけ
極端なチューニングによりコードを書き換えた時は、元の
コードも書き残しておいた方がいい（何をやっているのか
デモやギャラリー展示など、単発、単体の時は、苦労して
チューニングするよりも、速いマシンを調達した方が早い
メーカーが提供しているチップのドキュメントを読むとより
深く理解できます（特に PowerVR や NVIDIA系は充実）

64. PDF download
http://goo.gl/
Thanks!
@yukio_andoh