若干さぼり気味ではあるものの、グラフィックスAPIを抽象化する作業を行っている。今はファクトリ部分を作っているところである。このあたりの抽象化のレベルをどの程度にするかが、非常に悩ましい。実装を進めながら勉強しているので作り直したりクラス名を何度となく変更したりとなかなか進まない。デフォルト構成であれば簡単にオブジェクトが生成でき、必要なレンダラーが用意されて簡単に描画処理が行えるようにしたい。そうなるためにはこのあたりの知識に精通しておかないと何が一番簡単が判断できないので、実際の実装に必要な時間の何倍もの時間を学習にかける必要があり、このあたりを端折りたい私にとっては何か本末転倒な気がしなくもない。
まださきになると思うが具体的に方法が固まっていないのがコントロール(ウィジェット)を一つのグラフィック・コンテキスト(Direct2D/Direct3D)で描画する方法である。WindowsはコントロールひとつひとつがウィンドウでありそれぞれにHWND(ウィンドウハンドル)を持つ。描画メッセージはHWNDごとに発生する。通常はそれぞれのコントロールが持つウィンドウプロシージャで描画イベントをハンドル（描画処理）するのだが、これをフックで横取りしてグラフィック・コンテキスト(Direct2D/3Dの)を使って描画しようと考えている。グラフィック・コンテキストを使って描画するという言葉はかなり違和感がある。コンテキストとは属性とか設定情報を表す言葉だからである。しかしDirect2D/3Dではコンテキストは描画メソッドも併せ持っているのでこう書くのが実際に近い表現となる。なんとも変な感じだが。 それはさておきそうする場合HWNDごとに描画ターゲットを切り換えるのが普通のやり方だが、こういう描画ターゲットを切り換える処理というがなんか遅い感じがするので、そうでなくて個々のHWNDの親ウィンドウを基準とした座標系で親ウィンドウに描画するという方法でできないかなと考えているが、Direct CompositionやらDWMやらが頭にちらついてきてなんかその辺をうまく使えないかなとか、そのあたりと描画に関する調整・調停をしなくてはいけないんじゃないかとか、なんかモヤモヤした考えが浮かんできていてまとまらないのである。まとまらない原因というのはDirect CompositionやらDWMの知識不足によるモヤモヤ感であるので、解消するにはMSのドキュメントを読み込んでいくしかない。しかし若い時と違って一度ドキュメントを読んだだけでは頭に入らず、何度も反芻しないと消化できない牛のような脳になっている現在では時間がかかる。でも時間がかかるが40代後半でも記憶はできるので、中年後半というイタイ現実にめげずに頑張っていこうと思っている。
しかしやっぱりデスクトップ・アプリのほうがWindows Store アプリよりもできることが圧倒的に多いし、自由度も高い。Windows Store アプリのように制約をきつくするのが今のAPIのトレンドなのかもしれない。こういうAPIセットになっているということは他の先行しているOS(iOSやAndroid)もそうなっているのではないかと推測する。だいたいMSというのは他の先行技術をベースに独自的な色を付けて出すのが常であるからね。でもよく独自色が改悪だったりするのでひょっとするとこのWindows Store AppのAPIセットの不自由さは他のOSでは普通にできることなのかもしれない。まあ他のOSをいじる余裕はないので検証することはできないのだが。
過去の例で改悪であったと思われ、かつ私にとって影響が大きかったのはWASAPIかなと思う。Windows OSにとっては改善ではあるのだがCore AudioやASIOに較べると構成が複雑すぎ、性能も先行技術に追い付いていない。それでも愛着はあって使うことは使うのだが。