モバイルGPUベンチマークテスト: スマホFPSと熱ガイド

スマートフォンとタブレットには厳しい電力と熱の制限があります。WebGL benchmark の開始時は高い boost clock で動いても、熱がたまるとより低い sustained level に落ちることがあります。

ブラウザの違いも大きく影響します。Safari、Android Chrome、Samsung Internet などは WebGL 経路、timing、shader precision が異なる場合があります。つまり score は device だけでなく device plus browser の結果です。

画面サイズと device pixel ratio も記録すべきです。小さな canvas に見えても、高い pixel ratio では実際に描いている pixel 数が大きくなり、FPS と frame time が変わります。

最初は低い複雑度から始め、すでに熱い端末では長い run を避けます。端末は空気が流れる安定した場所に置き、手で覆わないでください。

一度の短い run だけで評価しないでください。開始直後の FPS と、60 秒または 3 分後の sustained FPS を分けて記録します。画面が暗くなる、ブラウザ操作が遅い、端末が非常に熱い場合は停止します。

再現性のある比較では、画面向き、明るさ、バッテリーモード、ブラウザ、実行時間を固定します。充電中と非充電の結果は同じ表に混ぜないでください。

iPhone Safari、Android Chrome、Samsung Internet、desktop Chrome を未注釈の ranking に混ぜると誤読しやすくなります。ブラウザ engine、GPU backend、画面 scaling、thermal policy が違うからです。

まず狭い比較を行います。同じ端末で browser を比べる、同じ browser で 2 台の Android を比べる、同じ iPhone の OS 更新前後を比べる、といった設計のほうが結論が明確です。

公開する場合は、OS version、browser、orientation、brightness、charging state、cold device か warmed device かを添えてください。これで casual score が再現可能な mobile GPU benchmark note になります。

native benchmark は深い telemetry を出せますが、web page performance の問いに直接答えるとは限りません。ブラウザ WebGL テストは、実際の web app が使える graphics path、tab scheduling、context stability を見せます。

WebGL game、shader demo、3D product page、creative coding sketch、GPU-heavy browser experience では、この視点が重要です。native score が高い端末でも、web graphics path が制限されると frame time は不安定になります。

最も良い評価は両方を使います。ブラウザ benchmark は web path の確認に使い、温度、clocks、hardware fault が必要な場合は native diagnostic を使います。

端末モデル、OS version、browser、orientation、brightness、charging state、duration、平均 FPS、1% low FPS、thermal drift を同じ行に残します。条件が見えない mobile score は再現しにくく、検索から来た読者にも使いにくい結果になります。

WebGL context loss、画面 dimming、touch response の低下、browser control の遅れがあれば、成功 score ではなく failure note として記録します。モバイルでは failure mode 自体が有用な benchmark 情報です。