できた。

特定位置にカーソルが来た時にニョキっと
枠描画するUIも出来た。
javascriptで鍛えた速度処理が役に立った。
次はアフィン変換しながらのトランジションか。
検証の意味合いが強いので微妙ではあるが。
やらざるを得ない。
しかし、そろそろ遊びたいので外に出る。
こもりっきりは良くないヨネ。

フォント描画完成。
早い。解像度精度10倍でやってても早い。

背景色を加味した上での2重の透過度の扱いに
滅茶苦茶時間かかった。
白は255.255.255だが周辺色との関係でのα値と
実際に描画する際のα値を考えるとその計算式が
画面の通りである。
兎に角時間かかった。

同日　17:11
3連デバイスコンテキスト組んでクリック即表示、
文節によるストップ可能、連続透過表示可能な
文章表示プログラムできたで。

解像度精度10倍を維持するには対応サイズの
ビットマップ3つ用意すると管理しやすかったね。
メモリリークしていないかも確認済み。
GetGlyphOutlineで最小範囲算出してから
配置してるのがメンドクサイ所だなぁ。
プロポーショナルフォントとかの特性を
活かせるっちゃ活かせるが、
文字位置の調節が面倒かもしれんね。

同日　21:06
トランジション命令判定とその枠組みまで実装。
処理中に命令文が来た時には一旦現状の文字列まで
全部描画した上で、命令文と内容を処理して、
しかる後に元のスレッド処理に戻る用に組んだ。
で、肝心のトランジション処理だが、
頭の中ではできているものの面倒なので明日に回す。
手始めに、黒色度判定してみようと思う。
吉里吉里のトランジションレイヤーと同じやね。
アフィン変換とかの座標変換系と
アニメーション画像読み込みどちらが早いかも
パーティクル実装の検証としてやりたいが、
それは後で。

ImeUi.cppのImeUi_ProcessMessage読んだ。
ANSIとUNICODEでIMEの処理を変えてる。
WideCharに対する扱いでキャレット等の
位置関係が変化するので、
そこまで計算した上で値を登録して描画反映してた。

で、ここでは実際に描画する訳ではなく、
（ここで描画する場合はCallback指定と
virtualの実装が必要。）
描画部分はDXUTgui.cppにあった。
最終的にテクスチャを登録してDirectXのDRAW。
キャレットはRECTを用意して、予め取得しておいた
位置関係、点滅秒数で点滅しているように見せかける。

実に巧妙な騙し処理だった。
SendKeyMsgとかCancelCompStringの扱いが肝。

同日　12:48
http://marupeke296.com/DXG_No66_OutlineFont.html
に倣って文字列描画をwindows.hのみで作成。

ナルホド、これなら高速描画できるかも。
前作ったDirect3Dテクスチャフォントでは
速度面で不安があるという結論だったので
単純に2Dの透明度加味した処理なら
こちらの方がかなり現実的だと目から鱗である。
こいつをクラス化するのを次の目標としよう。

結局DirectX読む羽目になるというね・・・。
EditBoxの定義をDXUTから遡る事、5時間。
RegisterによるDialogの登録や、COMによる登録
まで見てしまったが、要点はアレだ。
MSDN
http://msdn.microsoft.com/ja-jp/library/bb206300(v=vs.85).aspx
が間違いなく答えだ。
WM_INPUTLANGCHANGE
WM_IME_SETCONTEXT
WM_IME_STARTCOMPOSITION
WM_IME_COMPOSITION
WM_IME_ENDCOMPOSITION
WM_IME_NOTIFY
を自分で全て制御するようにプロシージャを
通す必要がある。
この際、デフォルトのIMEレンダリングを
使わないように適宜return falseを入れて
DefWindowProcに通さない部分が出てくる。
WM_IME_NOTIFYのIMN_OPENCANDIDATEで
LPARAM=0返せばいいかと思ってたが、
そんな単純な話ではなく、正直半端無く面倒。
ImeUi.cppのImeUi_ProcessMessageが根幹か？
クラス内のvirtualでオーバーライドしてる点も
かなり勉強になった気がする。
ID3DでSetTextureとかしてるのが見えたり、
COMの根本的な原理を知ってたから判ったが
数年前の自分じゃ確かに無理だったな・・・。