スポンサード リンク

T.Ishii's Software Library

HTML5 レトロ風ゲーム館

無料ブログはココログ

« 時すでに遅し? | トップページ | ここでまた1週間休む »

HiDPI対応の傾向と対策

昨日書いた様に、近日中にリリースしようとしているWindows版AG-ムービーカッターの不具合修正版では、Windows環境における最難関である所のPer-Monitor DPIにも対応できた感じなのだが、その為には、この前リリースされたWindows10のCreators Updateが必須だ。

ここ数日、Windows環境におけるHiDPI対応について色々と書いてきたのだが、要約すると、HiDPI対応というのは、従来以上の表示密度を持つモニターをWindows環境で利用する場合に、各ソフトに必要とされる対応、という事になる。

そして、そのレベルには、「System」と「Per-Monitor」の二つがあるのだが、今時のソフトでも、「System」レベルの対応は行えていても、「Per-Monitor」レベルの対応は行えていない、というモノは多い筈だ。

例えば、現行のAmuseGraphicsファミリーソフトは、基本的には、System DPIには対応させているのだが、Per-Monitor DPIには対応させていない。その理由は、Per-Monitor DPIに対応させるのは困難、というよりも、実質的には不可能だったからだ。

これは何故なのか、というと、まず、Sytem DPI対応というのは、従来は、PCのDPIは96DPIに固定されていたので、画面描画はそのDPIに合わせて決め打ちのサイズで行われていたのだが、96DPI以外のDPIが使われる可能性もある事を前提として、それに合わせて、画面描画を行う様にする対応、という事になる。

ただし、System DPI対応では、DPIは一種類しかなく、ソフト動作中には変化しない、という事を前提条件と出来る。

なので、対応は比較的簡単なのだが、Per-Monitor DPI対応では、DPIは接続されているモニター毎に異なり、ウインドウを移動して描画するモニターを変化させた場合には、そのモニターのDPIに合わせて描画サイズを動的に変更する必要がある。

と、いう事で、Per-Monitor DPI対応はSystem DPI対応よりも、困難になるのだが、例えば、ノートPCを普通に使っている様な場合には、モニターは一つしかないので、System DPI対応だけでも、ほぼ、何の問題も発生しない。

つまり、ある意味、労多くして益少なしな感じなので、それだけでも、Per-Monitor DPI対応は、やりたくない所ではあるのだが、実際問題として、Per-Monitor DPI対応が、ここまで、誰にも相手にされて来なかった理由は、別の所にある。

その話についても、ここ数日で書いてあるのだが、もう一度書いておくと、タイトルバーだとかメニューなんかの、所謂、非クライアントエリアだとか、ダイアログなんかは、普通はOSの機能を使って描画するモノなのだが、そのOSの機能が、前述のPer-Monitor DPIに対応していなかった訳だ。

つまり、WindowsのPer-Monitor DPIでは、ソフト側に対して、Linux環境でGTKだとかQTを使わずに、X-Windows関数だけを使って、メニューだとかダイアログを構築するのと同等程度の労力を費やす事を要求していた訳だ。

と、いう事で、Windows環境では、長らく、マトモなHiDPI対応は行われてこなかったのだが、その原因は、普通に鑑みれば、ソフト開発者の怠慢にあった訳ではなく、Windowsの構造にあった訳だ。

ところが、その辺の問題が、Windows10のCreators Updateで、大幅に改善された訳だ。

具体的には、新機能を使う、と、宣言したソフトに対しては、前述のタイトルバー/メニュー/ダイアログのOS描画が、Per-Monitor DPIに対応する様になった。

このため、ソフト側としては、ウインドウ内の自前コンテンツに対する対応だけで、Per-Monitor DPI対応が可能になったので、対応は不可能、という事はなくなった訳だ。

もっとも、この新しい機能を使うと宣言すると、ソフトのメインウインドウとダイアログについては良い感じになるのだが、メインウインドウとは独立した別ウインドウの描画は、より一層、訳が分からない感じになるかもしれない。

具体的には、AG-ムービーカッターの場合には、フルスクリーン描画をする場合に、通常はメインウインドウの子ウインドウにしてあるDirect2D描画用のウインドウを独立させ、そのサイズを全画面分にしていたのだが、前述の機能を使った場合、サブモニター側に、そのウインドウを正しく描画する事が出来なくなった訳だ。

その理由は、OSによってAPIの座標系が弄られてしまうから、の筈なのだが、作者的な感想としては、何となく、そんな単純な話では無さそうに感じた。

このため、AG-ムービーカッターのフルスクリーン描画については、その方式自体を変更し、Direct2D描画用のウインドウは、フルスクリーン時にも、メインウインドウの子ウインドウであり続ける格好した。

その結果、AG-ムービーカッターでは、フルスクリーン描画についても、何とか格好は付けられた訳なのだが、より複雑なソフトでは、Creators Updateの新機能を使う事で、色々と問題が発生する可能性はあるかもしれない。

まあ、だからこそ、このCreators Updateの新機能は、使うと宣言しないソフトには適用されない様になっているのだろう。

ちなみに、作者的には、AG-ムービーカッターに続き、AGMPlayerについても、同様のPer-Monitor DPI対応を行うつもりなのだが、多分、これについては、問題は発生しない筈だ。

しかし、作者的には、更に、同様の対応をAmuseGraphics本体だとかMirror-DTCサーバーだとかAG-デスクトップレコーダーなんかのキャプチャー系APIを使ったソフトでも、やってみようか、と、思っているのだが、多分、これらでは、何かしらの問題が起きる様な気がする。

いずれにしても、不具合修正版AG-ムービーカッターのリリースは、AGMPlayrer / AmuseGraphics本体の変更確認後にするので、来週の中頃以降になる筈だ。

« 時すでに遅し? | トップページ | ここでまた1週間休む »

トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/534482/65210089

この記事へのトラックバック一覧です: HiDPI対応の傾向と対策:

« 時すでに遅し? | トップページ | ここでまた1週間休む »

2017年10月
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        

広告

プライバシーポリシー

  • 当サイトでは、第三者配信による広告(Google Adsense)サービスを利用しています。

    Google を含む第三者配信事業者は、Cookie を使用して、ユーザーのウェブサイトでの閲覧履歴に基づく広告を配信します。 Google 広告 Cookie を使用することにより、Google や Google のパートナーは当サイトや他のサイトへのアクセス情報に基づく広告をユーザーに表示できます。

    Cookieを無効にする設定およびAdsenseに関する詳細については、以下のリンクを参照下さい。

    広告 - ポリシーと規約 - Google