2024年8月11日日曜日

PIX GPUキャプチャ失敗

今までDirectXの描画でうまくいかない部分をPIXで確認して何度もヒントを貰って直せた。

ところが突然PIXのキャプチャに失敗するようになった。
直前に直したであろうソースを戻しても記憶が曖昧でうまくいかない。
それから2,3日キャプチャができない日が続いた。

ネットで調べると、サスペンド状態で実行してキャプチャすると成功するというのを見つけ、試してみるとたしかに成功した。
ただこれは狙ったタイミングではキャプチャできず、一番最初のみうまくいく。

その状態のまま開発を続けたが、どうしてもキャプチャしたい状態が出てきてちゃんと調査することにした。


ほとんどの動作をコメントにして、キャプチャできるかを試したら久しぶりに成功した。
この状態から徐々に処理を開放していき駄目になる部分を特定した。


最終的に原因の特定に成功。


キャプチャ失敗の原因



最終的に失敗していた箇所が中間レンダーターゲットをテクスチャにコピーする処理だった。
このコピー前後にバリアを張っていたが、外してもデバッグレイヤで怒られないので不要なことはしないようにコメントアウトしていた。
実はこれが原因でPIXのキャプチャ失敗するようになったようだ。

バリアを戻すと、PIXでキャプチャが成功する。
実際の動作には何の問題もないがPIXのために必要なのか、それともデバッグレイアのチェックが抜けていて実は必要な処理なのか?

PIXでキャプチャできないのは困るので、バリアのコメントを外して復活させることで解決した。

2024年8月4日日曜日

文字列を描画する仕組みをレンダリングエンジンに組み込む

文字列を描画する仕組みは作ったけど、レンダリングエンジンへの組み込みが中途半端になっていたので、きちんと組み込んでみた。


文字列の属性


最初はFPSなどを描画する為に毎フレーム更新する前提のものを用意していたけど、ラベルのように設定したら更新されないものにも対応したいと思っていた。

SetText(一時的なテキスト設定)


毎フレーム更新される前提で、Update内で毎回設定する。
前回のテキストはクリアされ設定しなければ描画されない。

SetLabel(ラベルテキスト設定)


毎フレームは変更されず、更新のあった場合だけ再描画する。
利用側は毎フレーム書き込んでもいいし、書き込まなくてもよい。
管理側でID別に文字列を管理し、関数が呼び出される度に値を比較し変更があった場合だけ描画する。


出力先の設定


今までレンダーターゲットにのみ書き込んでいた。
SetTextは直接レンダーターゲットに書き込み、毎フレーム必要な文字列を描画する。
SetLabelは中間レンダーターゲットをキャッシュに利用できるようにする。
専用の単一中間レンダーターゲットに対して書き込み、変更がなければそのまま維持される。(ダブルバッファで用意してないのは前回の書き込みを利用するため)
描画完了後、別途テクスチャにコピーする。実際の画面への描画はこのテクスチャを貼り付ける。


出力方法


SetTextの場合は、主にレンダーターゲットを想定しており全体がクリアされたところに描画する。
SetLabelの場合は、状況により全体クリアと部分クリアを切り替える。
 

部分クリア


最初に描画位置を設定して文字列を描画する。
この時の描画範囲を記憶しておく。
次回描画時に前回記憶してある範囲だけをクリアして、新しい文字を書き込む。
大量のラベルを貼り付けても、実際に描画するのは最初と書き換えたときのみ。書き換えた場合もその書き換えた文字列のみの描画だけで済む。
ただし制限として文字列同士が重なり合うような場合は強制的に全体を描画し直す必要がある。

全体クリア


前述の通り初回の書き込み時と、文字列が重なるような状況の場合は強制的に全体クリアを行う。文字列が重なる場合、各ラベルの描画範囲を確認して重なる対象のラベルだけ部分クリアも可能だけど、ライブラリ内では重くなるから行わない。
利用側が重ならないように使うか、重なる状況の場合は強制クリア、もしくはSetTextでの描画を選択してもらう。


ハマりポイント



ClearRenderTargetView


部分クリアはこの関数の引数に渡す複数の矩形で行っている。
動作させてみると落ちる。
設定した矩形の数が61個で呼び出していた模様。
これを試しに1つに変更したら動いた。いままで0でしか動かしたことがなかった。
10、20、30と増やしても動き、50にしたらだめだった。
予想は32個で、31、32、33と試したら33で落ちた。
制限についてネットで調べてみても出てこない。
似たようなので見つけたのはClearUnorderedAccessViewUint関数の指定できる矩形の数が127だったという記事。環境に依存するのか、DirectXの仕様として決まっているのかもわからない。とりあえず数が多い場合は32ずつ処理するように修正した。



2024年4月29日月曜日

Text Services Framework (TSF)のつづき

以前TSFについて実装した。
TSFにまつわる文字入力と、それを表示する仕組みの部分にいくつかのバグが見つかり、ここ何日かで直していた。


バグその1


開発当初から気づいてはいたんだけど、放置していたバグ。
入力文字をテクスチャに展開していき用意していた領域全部を使ってしまった場合、先頭に戻って1行分をクリアして再利用するようにしている。
このとき、表示するデータの中に1行目のテクスチャを利用する文字が含まれていた場合表示されなくなってしまう。

この不具合の修正は、次に消えるであろう数行に表示データが含まれている場合は、最新部分に移してしまうようにすることで対処してみた。

実際に実装はしてみたがそのチェック処理が若干重めになるのと、実際に不具合が起きた際に起きる表示が1フレームだけ表示されない(もしくは別の文字で表示される)だけなので、あえて元のままにした。


バグその2


漢字変換を通さない文字入力(半角アルファベット入力など)をした直後に、漢字変換をしようと、文字入力をすると入力できないというもの。
状況によって、変換候補だけが表示されたり、更に文字入力すると表示されるようになったり、ならなかったりという現象が起こった。

現象はMicrosoftIMEで起きて、Google日本語入力では起きない。
幸い現象は100%起こせて、いつでも検証出来たがなかなか原因がつかめなかった。

何回も試しているうちになんとなく原因はわかった。
通常はITextStoreACPの継承関数がコールバックとしてTextStore側から通知される形だけど、文字変換を通さない入力の場合、ロックを掛けて、カーソル位置や内部文字を変更してアンロックをして、TextStore側は変更内容を知らない状態。勝手にこっち側で内容を変更しただけなので、文字列が増えたことが伝わってない状態で文字列外のカーソル位置に入力しているように見えてるのではないかと推測した。
GetSelectionや、GetTextなどが呼ばれて内容が変わってるのはわかってるはずなんだけど、MicrosoftIMEはわからないらしい。

その線で調べてみた結果、ITextStoreACPSink::OnTextChangeを呼べばいいのではないかと言うことにたどり着いた。
試しに実装してみると正しく入力できるようになった。
他にもこちらだけで内容を変更している箇所がいくつかあったので通知を加え、ついでにカーソル位置が変わったらITextStoreACPSink::OnSelectionChangeも呼ぶようにしてみた。


バグその3


毎フレーム登録して描画するのは非効率なので、ラベルとしてID付きで登録できるようにして、更新がなければStructuredBufferの更新をしないようにした。また一部のラベルで更新があった場合でも他のラベルのバイナリを再作成不要なようにバイナリを保持するようにした。

試しに100個のラベルを登録して毎フレームの登録がなくなりCPU使用率が下がって、GPU使用率だけが増えることを確認しようとしたところプログラムが落ちてしまった。

このデータ管理に自作ライブラリのHashMapを利用していたが、今まで発覚しなかったバグを見つけた。
調べてみるとHashMapの拡張時にデータの移行がうまく行っていなかった。
キャパシティの75%以上になったタイミングでデータ拡張を行い今までのデータを新しく確保した領域に移す。
テンプレートに指定された型がstd::is_trivially_copyable_vがtrueなら要素をまとめてmemcpy、falseなら1要素毎にnewする仕組みに振り分けている。
moveで例外を飛ばさない(std::is_nothrow_move_constructible_v)という暗黙の条件もつけていた。この条件に合致しない型を指定した状態でmoveを行うと何もしないようにしていた。
今回指定した型がちょうどstd::is_nothrow_move_constructible_vでfalseを返しており、データ拡張時元データを引き継いでいない状態になっていた。

構造体にいくつかの型が含まれているが、自作ライブラリのすべてをstd::is_nothrow_move_constructible_vにしているつもりだったけど、そうでないものが含まれていた。
UTF-8用の文字列クラスがあり、バイナリクラス(vectorのunsigned char型)を継承して作っていた。バイナリクラスはstd::is_nothrow_move_constructible_vはtrueで問題ないが、これをテンプレートクラスで継承した型の場合、スーパクラス側の自身のmoveコンストラクタとmove operator=が表面に届いていないようで、別途定義する必要があった。

必要な定義を追加して、move時std::is_nothrow_move_constructible_vでない場合はassertを入れつつ、copyを呼び出すように修正。対応していない型のmoveに気づくようにするのと、最悪このままreleaseビルドした場合でも動くようにした。


バグその4


UTF-8型の文字列クラスにもう1つバグがあって、ICUの機能を組み込んで見た目の文字数を取得できるようにする際、BreakIteratorのキャッシュを用意していた。
一度書記素単位に分けた情報を作ったら、次回はそれを使い回す。
今自分で書いていてもすぐに起こるであろうバグそのままが起きていた。
登録されている文字の変化があった場合、キャッシュのクリアが必要だったがクリアしていなかったためバグその3を直したあとに文字化けするようになった。
内容が変化し得る箇所にクリア処理を追加した。


バグその5


「バグその3」を引き起こした機能の実装でバイナリをキャッシュに問題があった。
データの更新に合わせてキャッシュはクリアしている。
ただ「バグその1」で起こっていた、テクスチャが書き換わった際のフォローが抜けている。

テクスチャの書き換えが起こったら、すべてのキャッシュを削除するようにした。
本来は利用していたものだけキャッシュを削除すればスマートだが、厳密にチェックするとなると重くなる。「バグその1」で妥協したように処理済みデータに対してキャッシュを消してしまっても、表示されないのは1フレームのみなのでこちらも妥協することにした。

これも対応してみたはいいけど、テクスチャ書き換えの度に文字がフラッシュするので、キャッシュ消す必要もない。どうせフラッシュするならそのままにすることにより影響受けるとこだけに抑えられる。結局何もしないことにした。
「バグその1」はフラッシュしないところまで実装したけど、こっちの方は今のところフラッシュしない方法を思いついてない。





2024年3月16日土曜日

シェーダに符号付き8ビットデータを渡す

前回のステンシルバッファでテキストのクリッピングをやろうとしたけど、単純な矩形をステンシルバッファへ書き込む方法がまだわからないので方針を変えることにした。

ステンシルバッファをClearDepthStencilViewの最後の引数に複数渡せる矩形情報でクリッピング範囲を指定できたら良かったんだけど、クリアの値が作成時のクリア値以外で書き込むとパフォーマンスが落ちるらしいので諦めた。


テキストのクリッピング処理


テキストをレンダリングするシェーダに渡しているSRVに16ビットのオフセット情報を増やして、書き込む幅を調整できるように考えた。

今まで渡していた情報はすべてuint16_tで描画する位置のx, yと、フォントマスタのインデックスno、カラー番号cno。
このデータサイズが毎フレーム更新に影響を与えるために極力小さくするチューニングを行って現在の形になっている。データを増やすのはかなり抵抗があるが致し方ない。

int16_tでオフセットofsを追加した。
マイナスの場合は左から、プラスの場合は右からオフセット分描画しないようにする。


普通に2バイトのデータを書き込んでシェーダ側でint16_tとして解釈すればこれについてはなんの問題もなかった。
ただ、1文字内で左右どちらもクリッピングはできないという制限はあるがこれは許容した。

ここまで出来て、縦方向も欲しくなった。エディットボックス内の文字列描画で、枠以上の文字列入力が可能な場合にクリッピング処理が発生する想定で作っていたから、縦方向は仕様次第で不要な状況にできるかなと思っていたけど作ることにした。

符号付きの16ビットの範囲は32767~-32768なので1文字に使う範囲としてはもったいない。これを符号付き8ビットにすると、127~-128なのでちょうど良い感じ。8ビットシフトして、上位8ビットに水平方向のオフセット、下位8ビットに垂直方向のオフセットを渡すようにした。

HLSL側でもシフトが普通に使えるので、水平方向のオフセットは右シフトで普通に取り出し、下位8ビットは「& 0x00FF」で上位8ビットを切り捨てた。
ところがこれだと渡した値が、プラスの場合は問題ないが、マイナスの場合正しく評価されない。

試してうまく行ったのは、一度左に8ビットシフトしてから、右に8ビットシフトする方法。上位8ビットについては右シフトで算術シフトできることはわかっていたので、下位8ビットも、最上位ビットにタッチさせて右シフトすれば行けるかと思ったら行けた。

他にもいろいろやり方はあるだろうけど、条件分岐一切なしにできたのでこれが良さそう。専用の関数(8ビット→16ビット)があれば別だけど。


今回の対応はVertexBufferにしてやれば、オフセット情報は増やす必要なく、書き込む位置とUVの調整で済むし、1文字内で両端のクリッピングにも対応できるけど、どうなんだろ?
フォントのマスタが不要になる一方、1文字4点分のデータ書き込みが必要になるから微妙か。

2024年3月7日木曜日

Stencil Buffer

今回はステンシルバッファについて


フォーマット



深度バッファのみのときは、DXGI_FORMAT_D32_FLOATを使っていた。
ステンシルバッファを使う場合は、DXGI_FORMAT_D24_UNORM_S8_UINTを使う。
Dの部分が深度バッファの精度で、ステンシルバッファに8ビット使ってしまうため、24に落ちる。
精度を落としたくなければDXGI_FORMAT_D32_FLOAT_S8X24_UINTというものもあるらしいけど、24ビット丸々無駄にするらしいし、4バイトの範囲に収まらないのでなんだか遅そう。


D3D12_RESOURCE_DESC1.Format


深度バッファのみのときは、DXGI_FORMAT_R32_TYPELESS
ステンシルバッファを使う場合は、DXGI_FORMAT_R24G8_TYPELESS


D3D12_CLEAR_VALUE.Format


深度バッファのみのときは、DXGI_FORMAT_D32_FLOAT
ステンシルバッファを使う場合は、DXGI_FORMAT_D24_UNORM_S8_UINT


CreatePlacedResource2.CastFormat


深度バッファのみのときは、
CastFormat[0]=DXGI_FORMAT_D32_FLOAT
CastFormat[1]=DXGI_FORMAT_R32_FLOAT
ステンシルバッファを使う場合は指定なし。

これがいまいち分からず、指定するとエラーになりCreateできない。
深度バッファの方は、指定する場合は両方指定しないとランタイムエラーになる。
指定なしにしたら動くので、下手に指定する必要がないかも。


D3D12_DEPTH_STENCIL_VIEW_DESC.Format


深度バッファのみのときは、DXGI_FORMAT_D32_FLOAT
ステンシルバッファを使う場合は、DXGI_FORMAT_D24_UNORM_S8_UINT

D3D12_GRAPHICS_PIPELINE_STATE_DESC.DSVFormat


深度バッファのみのときは、DXGI_FORMAT_D32_FLOAT
ステンシルバッファを使う場合は、DXGI_FORMAT_D24_UNORM_S8_UINT


D3D12_SHADER_RESOURCE_VIEW_DESC.Format


深度バッファのみのときは、DXGI_FORMAT_R32_FLOAT
ステンシルバッファを使う場合は、DXGI_FORMAT_R24_UNORM_X8_TYPELESS

ここを見るとPlaneSlice0にDXGI_FORMAT_R24_UNORM_X8_TYPELESS、1にDXGI_FORMAT_X24_TYPELESS_G8_UINTを指定する様に書かれている。
SRVでPlaneSliceを複数指定する方法がわからないけど、2つ指定するとそれぞれ深度バッファと、ステンシルバッファが参照できるのだろう。

今のところステンシルありのバッファをテクスチャ利用する予定はないので、必要が出てきたら調べることにする。


PSO


ステンシルバッファを使う場合は、DepthStencilState.StencilEnableをTRUEにする。

ステンシルバッファ書き込み


DepthStencilState.StencilReadMask = D3D12_DEFAULT_STENCIL_READ_MASK ;
DepthStencilState.StencilWriteMask = D3D12_DEFAULT_STENCIL_WRITE_MASK ;
DepthStencilState.FrontFace = {
    D3D12_STENCIL_OP_KEEP,
    D3D12_STENCIL_OP_KEEP,
    D3D12_STENCIL_OP_REPLACE,
    D3D12_COMPARISON_FUNC_ALWAYS
} ;
DepthStencilState.BackFace = DepthStencilState.FrontFace ;

上記は描画した場所をOMSetStencilRefで設定した値で塗りつぶす場合の設定(D3D12_STENCIL_OP_REPLACE)
D3D12_STENCIL_OPは3つ設定できて、最初がステンシルテストに失敗した場合、次がステンシルテストは成功したけど、Zバッファのテストが失敗した場合、最後が両方のテストが成功した場合。
ステンシルバッファの書き込みだけで、描画は行わない場合BlendState.RenderTarget[i].RenderTargetWriteMaskも0にするといいらしいけど、そもそもレンダーターゲットを指定しなければいいんじゃないのか?
バッファ書き込みはやってないので分からず。


ステンシルテスト


DepthStencilState.StencilReadMask = D3D12_DEFAULT_STENCIL_READ_MASK ;
DepthStencilState.StencilWriteMask = 0 ;
DepthStencilState.FrontFace = {
    D3D12_STENCIL_OP_KEEP,
    D3D12_STENCIL_OP_KEEP,
    D3D12_STENCIL_OP_KEEP,
    D3D12_COMPARISON_FUNC_EQUAL
} ;
DepthStencilState.BackFace = DepthStencilState.FrontFace ;

上記は、OMSetStencilRefで設定した値と同じ箇所だけ描画する場合の設定。


ClearDepthStencilViewでD3D12_CLEAR_FLAG_DEPTH | D3D12_CLEAR_FLAG_STENCILを指定して、深度バッファとステンシルバッファを初期化したあと、ClearDepthStencilViewの最後の引数に矩形を指定して、ステンシルバッファだけを10で初期化。OMSetStencilRefにも10を設定して描画してみると、こんな感じになった。

Hが欠けてる

指定通りの動作になっているけど、デバッグレイヤには下記の警告が出続ける。

D3D12 WARNING: ID3D12CommandList::ClearDepthStencilView: The clear values do not match those passed to resource creation. The clear operation is typically slower as a result; but will still clear to the desired value. [ EXECUTION WARNING #821: CLEARDEPTHSTENCILVIEW_MISMATCHINGCLEARVALUE]

ステンシルバッファの書き換えにClearDepthStencilViewを利用したのがだめみたい。
矩形で指定範囲を書き換えたい時、わざわざシェーダを通さずClearDepthStencilViewで手軽にクリップ領域を指定できるかと思ったけど、この使い方はだめみたい。



2024年2月27日火曜日

Multithread GPU Command

マルチスレッドでコマンドを発行する仕組みを作ったけど、久しぶりに見たらところどころ忘れてしまってたので資料としてまとめておくことにした。


コマンド発行の仕組み


コマンド発行の全体図


クラスはCommand、CommandList、ComanndAgent、CommandQueueの4つで構成されている。


CommandQueue


CommandQueueは以前はGraphics、Compute、Copyの3つ用意してそれぞれに発行できるようにしていたけど、フレームの途中で同期はしないようにすることを考えるとGraphicsのみで良いという考えに至り、1つのみ用意している。
またGPU処理完了でブロックしないように、Queue1つに付き、1スレッドが待機している。


Command


GPUに命令する最低単位。1命令文=1Commandで、要求するコマンドに必要なパラメータを管理している。


CommandList


DirectX12のID3D12CommandAllocatorとID3D12CommandListを内包するクラス。


CommandAgent


コマンドを内包し、実行タイミング要求で別スレッド経由でコマンドリストに追加する。
Agent1つに付き、1スレッドが待機している。


処理の流れ


①GetCommandAgent


動作スレッド:メイン
描画開始時、BeginRender内でプールからCommandAgentを取得する。

②AddCommand


動作スレッド:メイン
CommandAgentに対して、各種コマンドを追加していく。

③Execute


動作スレッド:メイン
CommandQueueにCommandAgentを移管して、CommandAgent内に眠っているスレッドを起こす。
同時にCommandQueue内に眠っているスレッドも起こす。

④GetCommandList


動作スレッド:CommandAgent
CommandAgent内のスレッドが、コマンド発行用のリストをプールから取得する。

⑤AddCommandList


動作スレッド:CommandAgent
ComanndAgent内に溜め込んだコマンドを1つずつコマンドリストに追加していく。

⑥ExecuteCommandLists


動作スレッド:CommandQueue
CommandQueue内のスレッドがCommandAgentを監視して、現在管理中のCommandAgentの処理が全て完了していたら、ExecuteCommandListsを呼び出し、GPUの処理を開始する。

⑦ReleaseCommandAgent


動作スレッド:CommandQueue
CommandAgentを返却する。
その際CommandAgentが抱えている各種リソースの開放を行う。
※厳密には、NextFrame内で呼び出される。

⑧NextFrame


動作スレッド:CommandQueue
切り替え先のフレームのGPU命令が完了しているかチェックし、終わっていなければ待つ。
終わっている場合はReleaseCommandAgentを呼び出す
次のフレームに切り替える。



課題


最初の頃はコマンドを追加するたびに、別スレッドでコマンドリストに追加して、全コマンドが追加できたらExecuteCommandListsを発行していた。
現在はCommandQueueにExecuteする単位でExecuteCommandListsする仕組みを用意はしているけど、実際にExecuteするタイミングは全コマンドを追加したらで変わっていない。
nVIDIAのドキュメントによると、1フレームで5~10回に分けてExecuteCommandListsを呼び出すと良いと書かれている。手動で分割するか、動的に判断するか今後考える。

またCommandAgent内のCommandListは複数持てるように設計しているが、現状利用しているのは1つのみになっている。更に、1フレームで複数CommandAgentを扱えるようにしているけど、現状利用しているのは1つのみ。全体で15~30くらいCommandListを保持して使い回すらしいので、複数のCommandListをまとめてExecuteするようにしたい。

※nVIDIAのドキュメントが以前「DX12 Do's And Don'ts」という題名のBlogだったけど、それぞれのトピックに分けて再構成されていた。最初なくなってしまったのかと思ったけど、1つ1つをよく見ると前と同じ内容だった。



2023年12月13日水曜日

DirectX12 DrawText その2

前にDrawTextをする為の仕組みをGetGlyphOutlineを使って作った。
Unicodeの特殊事例に対して対処できたのはサロゲートペアだけで、結合文字や絵文字に対してはGetGlyphOutlineでは扱えずビットマップが取得できない。
この時はDirect2DとGDIのどちらにするか迷ってGDIを選択したけど、絵文字も表示するとなるとDirect2D(DirectWrite)しか選択肢がなかった。


IDWriteTextRenderer


GDIのGetGlyphOutlineに当たる機能はDirect2Dでは何になるかを調べたところ下記になるらしい。
グリフ メトリック -- IDWriteFontFace::GetDesignGlyphMetrics
実際のアウトライン情報 --IDwriteFontFace::GetGlyphRunOutline
グリフ ビットマップ -- IDWriteRenderBitmapRenderTarget::DrawGlyphRun

更に調べていくと、マイクロソフトのサンプルのDWriteHelloWorld/CustomTextReadererにたどり着いた。

CustomTextReadererはIDWriteTextRendererを継承して作られたクラス。
前回、WicBitmapRenderTarget経由でIWICBitmapに書き込むことは出来ていたけど、今回はCustomTextReadererで書き込むことに成功。
今回はビットマップのフォーマットをGUID_WICPixelFormat8bppAlphaにすることにより、GetGlyphOutlineで得られるデータに近いものが得られるようにした。

で、Bitmap自体は取得できたけど、グリフ情報は得られていない。
IDWriteFontFace::GetDesignGlyphMetricsで得られるらしいけど、IDWriteFontFaceを得る方法がかなり難しそうで、ファイルを指定しないといけなかったり、IDWriteFontFamilyやIDWriteFontCollectionからもたどり着くのが難しい。
一体どうすればいいのか悩んでいたけど、CustomTextReadererの中に答えがあった。

CustomTextReaderer::DrawGlyphRun関数の引数内にglyphRunがあり、glyphRun.fontFaceがIDWriteFontFaceだった。
これを利用すれば、GetDesignGlyphMetricsが呼び出せてDWRITE_GLYPH_METRICSが取得できる。
IDWriteFontFace::GetMetrics関数でDWRITE_FONT_METRICSが取得でき、この2つを組み合わせると下記の情報が得られる。

fm:DWRITE_FONT_METRICS
gm:DWRITE_GLYPH_METRICS



gm.advanceWidthが次の文字までの距離で、GLYPHMETRICSで言うところのgmCellIncXに当たる値。

書き始めの基準が薄い赤の枠の左端で、次の文字の書き始めが右端になる。
左端はDraw関数に指定した位置で、右端はadvanceWidthを足した位置になる。
上辺は、Draw関数に指定した位置にfm.ascentを足して、gm.verticalOriginYを引いた位置で、下辺は、Draw関数に指定した位置にfm.ascentとfm.descentを足した位置になる。

実際の文字のデータが含まれる範囲(濃い赤枠)を得るには、薄い枠の範囲にleftSideBearing、rightSideBearing、topSideBearing、bottomSideBearingを引いた値となる。
Aの場合はすべての値がプラスで薄い赤枠の内側になる。
jの場合は、leftSideBearing、topSideBearingはマイナスで薄い青枠の外側になり、描画開始位置が前の文字と被ることになる。
(GLYPHMETRICSのgmptGlyphOrigin.xがマイナスの場合と同じ)

また、これらの値の単位が違うので変換する(fm.designUnitsPerEmで割って、glyphRun->fontEmSizeを掛ける)必要がある。
得られるのは小数点を含むデータでピクセル単位に変換する際、top、leftは切り捨て、bottom、rightは切り上げした。メイリオの通常ではこれで問題ないけど、別フォントでイタリックにすると、縦が1ドット足りない場合はあった。必要に応じてマージンを設定するといいかも。


絵文字対応



通常の文字であれば、1つのグリフ情報だけが得られてそのSideBearingを計算すればよかったけど、例えば「👨‍👩‍👧‍👦」の絵文字の場合得られるグリフ情報が4つ返却され、それぞれの絵文字のSideBearingを見るだけだと計算が狂ってしまう。

glyphRunにはglyphAdvancesとglyphOffsets(※)があり、glyphOffsetsにはさらにadvanceOffsetとascenderOffsetが含まれている。
これらの値は、前述の単位変換は不要。
※glyphOffsetsはnullの場合があり、その時は0扱いとする。

メイリオ24で「👨‍👩‍👧‍👦」のDrawを行うと下記のグリフ情報が得られる。
X Y W H A OX OY
父 2.0 4.6 14.4 17.0 16.4 4.9 0.0
母 13.1 4.7 15.2 16.9 13.6 0.0 0.0
娘 1.9 15.7 13.9 15.1 0.0 -25.4 0.0
息子 13.9 16.0 13.5 14.9 0.0 -13.6 0.0

X:advanceOffset + leftSideBearing
Y:ascent + topSideBearing - verticalOriginY - ascenderOffset
W:advanceWidth - leftSideBearing - rightSideBearing
H: advanceHeight - topSideBearing - bottomSideBearing
A:glyphAdvances
OX:advanceOffset
OY:ascenderOffset

父の描画範囲はadvanceOffset(4.9) + leftSideBearing(-2.9) = X(2.0)、ascent(25.8) + topSideBearing(-3.7) - verticalOriginY(17.4) - ascenderOffset(0.0) = Y(4.6)、advanceWidth(9.8) - leftSideBearing(-2.9) - rightSideBearing(-1.6) = W(14.4)、advanceHeight(22.5) - topSideBearing(-3.7) - bottomSideBearing(9.2) = H(17.0)という感じで算出される。それぞれの範囲を計算して、left、topの最小、right、bottomの最大を求めたのが絵文字全体の描画範囲となる。

上の方で「gm.advanceWidthが次の文字までの距離」と書いたが、実際にはglyphAdvancesの合計が次の文字までの距離となる。通常の1文字であればadvanceWidth=glyphAdvancesとなっているが、複数要素の絵文字の場合advanceWidthは、その要素単位の幅であって全体の幅には使えない。


結合文字対応



基本的には絵文字対応の内容で問題ないけど、よく5chなどでこんな書き込みがある。




m9(ด็็็็็็็็็็็็็็็็็Дด็็็็็็็็็็็็็็็็็)プギャーw

ブラウザ、VisualStudioのエディタはこの文字列の表示に対応してた。

VisualStudioエディタ

メモ帳は1行の範囲でクリッピングされていた。

メモ帳


いくらでも文字を合成できてしまうため、メモ帳と同じように制限を加える。
一時領域に描画しているため、水平方向に関してはマイナス、一時領域の幅以上の場合はクリッピング、垂直方向はマイナス、ascent + descentを超えた分はクリッピングする。

こうして見ると、ブラウザとメモ帳でadvanceOffsetの解釈が逆になっていて、VisualStudioはadvanceOffsetを無視してるっぽい。

スペース対応



最後にスペースの文字列について。
スペースはビットマップの範囲が0になっていたため、ビットマップ参照の為のLock関数でエラーになっていた。幅0の場合はビットマップ参照はスキップして、文字情報だけ書き込むようにする。
また描画の際、幅0の場合は何もせず次の文字までの幅だけを足すようにする。