ccmi: コンポジションAPIの調査
okuokuめっちゃ面倒くさい。。実アプリを展開するためにはコンポジションAPIを設計して実装する必要があるので調査する。(CCMI: Compact Composition Management Interface)
コンポジションAPI
C-WebGLはあくまでOpenGL ES2の機能性しか持っていないので、どうしてもそれだけでは実現できないポイントは別途API化する必要がある。つまり、
- レンダリングコンテキストの生成
- GPUがレンダリングした内容の 合成 表示
のような機能性を纏めてコンポジションAPIと呼ぶ。合成なんてOpenGLでやれば良いじゃん感はあるが、世間的な組込みではビデオデコーダーの出力をGPUが触れないケースがあり複数の映像出力ソースが単一アプリ内に併存するケースが普通に存在する。
Khronosはこの部分の標準化もしていて、 OpenWF が相当する。ただし、OpenWFは既にinactive standardとなっている。
まぁAndroid以外の組込みはほぼ絶滅してるし、そうでないところは直接Vulkanなり何なりを使えば良いからね。。
従来Linuxのフレームバッファー向けにDirectFBが存在したが、DirectFBも既に消滅している。ただし、そのforkがDirectFB2としてまだ生き残っている:
okuoku"モダン" ターゲット
とりあえず、HTML5をプライマリターゲットとして想定する。つまり、 <canvas> と <video> をブラウザ内でレイアウトするためのC APIを用意したい。
営業的にはWebXR Device API の Layers拡張 https://github.com/immersive-web/layers も含めたい。Layers拡張はそれなりの精度のpolyfill https://github.com/immersive-web/webxr-layers-polyfill が提供されているので、現時点でも存在を仮定して良い。
現代的には、2D、XRの両方で低レイテンシ出力を想定した機能性が必要になる。これはOS側のCompositorとの協業が必要で、例えばAndroidには専用のFramePacing ライブラリ https://developer.android.com/games/sdk/frame-pacing?hl=ja があり、画面が表示されるタイミングをwaitする手段を提供している。この領域のライブラリとしては NVIDIA Reflex もある。
超細かいが、マウスカーソルも画面合成可能なオブジェクトなので形状の操作はここに統合される必要がある。
okuoku拡大回転縮小
XRやDRMビデオケースでは専用の考察が必要になる。保留。また、SDL1は拡大縮小をサポートしていない。
2Dのコンポジションでは、Rect → Rectの自由変形(X軸Y軸で独立した拡大率の設定)はサポートしたい。ただし、負値を設定することによる上下または左右の反転はサポートしない。回転などもサポートしない(スプライトエンジンを別途設ける形にしたい)。
ブレンディング
かなり難しいトピック。。アルファ(opacity)だけで良いかな。。
SDL2はサーフェス毎に追加のalphaを設定できる。更にBlend modeも任意のものが使用できる https://wiki.libsdl.org/SDL2/SDL_ComposeCustomBlendMode 。
Web標準も考えつく限り任意のBlendingをサポートしている https://drafts.fxtf.org/compositing-1/ ものの、XR Layersではsource-overだけがブレンディングとして使用できる。Layersでは opacity が使用できる。
Glitchless リサイズ
ブラウザやOSのウインドウを変形した際にグリッチが生じない方が見た目が良い。これは電話で縦画面←→横画面の切り替えを行う場合や、ソフトウェアキーボードを表示するようなケースでも起こる。実現はかなり面倒で、GUIイベントをフィルタリングできるようにしなければならない。
例えばXRではリサイズ自体が発生しない。
マルチレイヤー
WebXRでは、 secondary-view がある。つまり、XRシーンに加えて追加の2Dシーンを描画できる。
WindowsにはMulti Plane Output(MPO)がある。 ...が評判が微妙で、かつ、Intelくらいしか真面目にサポートしていない気がする。
VRRおよびパワーセーブ
... 良い資料がないな。。画面の更新を抑えることでモバイルデバイス上では消費電力を削減できる。また、VRRに対応すれば、負荷変動が生じたケースでもフレームのティアリング等を抑えられる。
特殊Window
エディットコントロール、要するにテキスト入力欄を扱いたいという要求は常にあるが。。これfallbackを実装するのが面倒でねぇ。。
何も表示しないrootの色を黒とか白に固定したいという需要がある。これはbackgroundを特殊なWindowとして扱うことで一応対処できる。