意外と大変な事が判明

今は、Mirror-DTC Ver1.4.4の開発フェーズで、既に、Windows用はβ版を公開中だ。なので、作業はmacOS版の更新に移っているのだが、画面キャプチャーAPIが異なるので、対応モニター数を増やす変更は意外と大変な事が判明した。

Windowsの場合、画面キャプチャーは昔からあるBitBlt関数を使うか、Desktop Duplication APIを使う事になるのだが、作者製ソフトは、Desktop Duplication APIが登場する前から開発してきているので、初版の頃にはBitBlt関数を使っていた。

なので、プログラムの内部構造としては、BitBlt関数を使って画面キャプチャーが出来る様な構造になっていて、Desktop Duplication APIが利用可能になった後には、その構造の中で、このAPIを利用する格好に変更した。

その結果として、Windows版の画面キャプチャー処理は、全てのモニターが合成された仮想スクリーンに対して、必要な部分のみ領域指定して映像を取得する感じになっている。

つまり、「対象」を「ディスプレイ1」にしても「合成ディスプレイ」にしても、内部処理的には、画面キャプチャーする領域を変更するだけ！ みたいな作りになっている。

これに対して、macOS版の場合、画面キャプチャー処理はmacOS用のAPIの影響が見える感じになっている。

具体的には、画面キャプチャーはモニター毎にしか行えないので、「合成ディスプレイ」が指定された場合には、2モニター分のキャプチャーを独立して行い、それらの結果を合成して出力用のデータを作成している。

問題は、2モニター分のキャプチャーを独立して行い、と、いう所で、今回の更新では、最大サポートモニター数は2から8に変更するので、今回の更新で、2モニター分しかなかった各種リソースを8モニター分に増やす必要がある訳だ。

まあ、リソースを増やすだけなら、大した事はないのだが、現行の処理ルーチンというのは、各モニター用のキャプチャー処理を独立したコードで記述してある訳だ。

つまり、元々は、APIのテスト用にシングルモニター用の処理コードを記述し、その後、デュアルモニター対応にする時には、デバッグの容易性も考慮して、そのコードをコピペして独立した2つのコードが存在する格好にする事で、2モニター分の処理を行える様にしてあった。

と、いう事で、Windows版の場合、2モニター対応から8モニター対応にする場合、雰囲気的には、配列の要素数を2から8に変えるだけで、対応モニター数を増やせた感じなのだが、macOS版の場合、まず、各モニター用の処理を一つの処理コードを共用できる構造に作り替える必要がある事が判明した訳だ。

まあ、今現在、2個のコードがあるのを8個のコードに増やす、というのも手ではあるのだが、実際の所としては、そんな事をしてしまうと、コードの見通しは悪くなるし、バグも発生しやすくなる筈だ。

なので、とりあえず、macOS版サーバーについては、画面キャプチャー処理の内部構造から更新し始めた今日この頃だ。

ちなみに、Windows版については、仮想モニターを増設できるフリーソフトの「spacedesk」を使う事で、8モニター環境を作り出し、動作確認を行なったのだが、macOS版については、今のところ、デュアルモニターのMac mini M2 ProにiPad AirとMacBook Pro M1モデルを接続して4モニター環境を作って動作確認環境にする予定だ。

なので、今のところ、8モニター環境での動作確認はしないかもしれない状況なのだが、4つのモニターを二回ずつキャプチャーすれば、8モニター分のデータを取得できたりはする訳なので、そんな感じのデバック環境は構築する事になるかもしれない。

しかしまあ、前述の様に、macOS版については、キャプチャー処理の構造から作り直す事になってしまう様なので、そこまで行くのに、まだ、2,3日は必要になるかもしれない今日この頃だ。