結論と対象読者

スマートフォン向けのDotLCD Cameraでは、最大品質を常時維持するより、論理解像度、処理FPS、残像バッファ、高DPI倍率を段階的に下げられる品質モードを用意する方が安全です。ブラウザから端末温度を直接取得できる一般的なWeb APIは前提にせず、処理時間、FPS低下、ページ可視性、利用者の選択を判断材料にします。

30秒要約

  • 発熱はカメラ、GPU、CPU、高DPI描画、画面点灯の組み合わせで増えます。
  • Webページから端末温度を直接読む一般的な標準APIは前提にできません。
  • ページが非表示になったら描画と不要な処理を止めます。
  • 低負荷モードでは、論理解像度、更新頻度、DPR上限、残像処理を下げます。
  • 品質を自動変更する場合は、利用者へ現在の状態を表示します。

概要と背景

DotLCDは低解像度表現ですが、入力カメラが高解像度であり、毎フレームの縮小、画素読取、4階調化、ディザー、残像、高DPI拡大をすべて行うと、スマートフォンでは負荷が高くなる場合があります。

発熱すると、OSやブラウザがCPU・GPU性能を抑える可能性があります。その結果、FPS低下、入力遅延、カメラ停止、WebGLコンテキスト消失につながることがあります。

ただし、Webアプリが端末温度を正確に測定し、「何度だから危険」と判断する設計は一般的ではありません。負荷の兆候を観測し、品質を下げられる設計にします。

特徴・できること

段階的な品質モード

例として次の3段階を用意できます。

モード論理解像度目標更新頻度DPR上限残像
高品質高め高め2〜3有効
標準中程度中程度2軽量
省電力低め低め1無効または短縮

具体値は端末実測に基づいて決めます。

非表示時に処理を止められる

Page Visibility APIでタブが非表示になったことを検知し、描画、FPS計測、不要な画像処理を停止できます。カメラ自体を止めるかどうかは、復帰速度とプライバシー方針を踏まえて決めます。

実測FPSから負荷を推定できる

一定時間、処理時間が長い、フレーム落ちが続く、コンテキスト消失が起きる場合に、品質を1段下げる設計が可能です。ただし、FPS低下の原因が発熱とは限りません。

現在の位置付けと利用上の前提

Page Visibility APIは、ページが見えているかを確認するためのAPIであり、温度測定APIではありません。発熱の直接的な検知根拠として使わず、非表示時の無駄な処理削減に使います。

自動品質調整を行う場合、頻繁にモードを上下させると見た目が不安定になります。一定時間の平均、ヒステリシス、変更後の待機時間を設けます。

カメラ解像度を下げても、最終的なDotLCD論理解像度が十分に低ければ、見た目への影響が小さい場合があります。最終出力に不要な高解像度入力を要求しないことが重要です。

近い対象との比較

対応効果注意点
入力解像度を下げるカメラ・縮小負荷を低減カメラ制約の対応差
論理解像度を下げる画素処理量を低減表現自体が粗くなる
FPSを下げる継続負荷を低減動きがカクつく
DPR上限を下げる描画バッファを縮小高DPIで少しぼやける
残像を無効化バッファ処理を低減時間表現が弱くなる

確認/試行の条件と注意点

  1. 10分、20分、30分の連続動作を試します。
  2. 充電中と非充電時で挙動を比較します。
  3. 高品質、標準、省電力でFPSと操作遅延を記録します。
  4. タブを非表示にしたとき、描画処理が止まるか確認します。
  5. 復帰後にカメラと描画が二重起動しないか確認します。
  6. 自動品質変更が発生した場合、UIへ理由と現在モードを表示します。
  7. 端末が熱い、動作が不安定になった場合は利用を中止できる停止ボタンを常時表示します。

発熱を医療・安全上の温度判定として扱わず、Webアプリの負荷管理として説明してください。

参考リンク

  • MDN: Page Visibility API
  • https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API
  • MDN: Document visibilityState
  • https://developer.mozilla.org/en-US/docs/Web/API/Document/visibilityState
  • MDN: requestAnimationFrame
  • https://developer.mozilla.org/en-US/docs/Web/API/Window/requestAnimationFrame