2015/05/09 HiDPI対応 -生存競争- 2015/12/31 追記 Google先生によるとこのページが高DPI関連の注目度が高いようなので､ 関連URLを整理しておきます｡ しかし､ここは話の切っ掛けにすぎず､ それより次の具体的な話題の方が重要なので先生にはこちらを見て欲しいものです｡ というのはユーザ視点での話題は良く有れど 開発者視点の体系的且つ意味のある実装方法にまで踏み込んでいるのは 少ないためです｡ C++での具体的な実装方法: 　高DPI対応　その1　現状と普及が遅れる原因 　高DPI対応　その2　具体的な対策 世の中の対応状況: 　HiDPI対応 その2 -LetsNote SZ5を例に- やっと全てのWindowsアプリケーションを高DPIに対応しました｡ いや､大変だった｡特にマウ筋LiteとRyusMenuは｡ 前者はデザインだけでなく､想定外にも機能の方にも影響があり ジェスチャーがまともに機能しないということがありました｡ 機能にも影響を及ぼすなんて報告は無かったのにねぇ｡ 後者は既に語っているので､割愛しますが難儀しました そのおかげで､もうどんなアプリケーションでも高DPI対応できる気がします｡ (Per monitor DPI Awareには未対応｡対応できますが､そこまで手が回りません) 意外だったのがオンスクリーンボリュームビューアLiteです｡ これは何もしなくてもある程度対応していたので驚いたのですが､ 理由はMFCアプリだったからです｡ MFCはデフォルトで｢System DPI Aware｣が有効になるのです｡ とはいえ､何もしないで完全に対応する訳でも無かったため､ 手を加えています｡ ただ､pngTrimmerだけは対応方法が分からないですね｡ というのは､これ､Javaアプリなので対応方法が不明｡ HiDPI環境では以下のようにデザインが崩れて､ ボタンが円環の理に導かれてしまうので操作不能になります｡ どうしたらいいでしょう｡正直NoIdeaです｡ もしかしたら最新版のExcelsior Jetでは再び奇跡を起こせるのかもしれません｡ HiDPI環境 非HiDPI環境 さて､一般的な話に観点を移しますが､ 高DPI問題はこれから大きな問題となるでしょう｡ de:code 2014のセッションでは今後3年以内とありましたが､ いや､もう問題が出ていました｡特に私には｡ C++アプリ向けの解法の1つがMSDNにて語られています｡ これだけで済むわけではないですが取っ掛かりにはなります｡ 直接処理に手を入れられる立場ならば良いのですが､他者の製品の場合はそうはいきません｡ 対応するかどうかは他者に依存し､ 対応しない場合は今後使用できなくなる可能性があります｡ そう､高DPI対策は機能自体が使用できなくなることを防ぐクリティカルな課題なのです｡ 最悪､互換性維持用の" Not DPI Aware"のぼやけた画面でガマンすれば とりあえず凌げるように見えますが実際にはそれで済まないケースが出てきます｡ そのため必須のソフトウェアがある場合は 高DPIに対応するかどうかをチェックする必要があるかもしれません｡ 私のお気に入りの作品達はいつまで使えるようにすることが出来るのでしょうか｡ マウ筋は"win7 x64に対応不可"の問題を解消することで延命しましたが､ 次の壁はwin8の高DPIでした｡ Ryu's Menuは16bitアプリのため､win7のx64では使用不可のところを 32bit化することで延命しましたが､同じく次の壁は高DPIでした｡ オンスクリーンボリュームビューアはVistaでオーディオAPIの仕様変更というか刷新により 対応不可のところを新APIに対応させましたが､ 高DPIでは一部の機能が正常に動作しませんでした｡ なんかOSの版数が1つ上がる毎に致命的な問題が発生していますが Windows10ではどうなるんでしょうか｡ de:code 2015ではWindows10関連の情報が明かされるようなので 探ってみたいですが､いかんせん費用の面で参加することが困難です｡ 豪華な"おみやげ"無しでいいので無償で参加したいものです｡