2014/06/07

WPFにおけるPer-Monitor DPI対応の実装

先日参加しためとべや東京勉強会でぐらばくさんが現在のWPFについてセッションされた中でHigh DPI対応について説明されてました。丁度同じ日にプログラミング生放送勉強会で八巻さんがWindowsの画面スケーリングについてセッションされたようで、共通したメッセージとして、High DPI、さらにはPer-Monitor DPIの時代がとっくに来てるのでアプリは対応していく必要がある、ということでした。
一方、Per-Monitor DPI対応を実装しようとすると未解決の部分があって、少しお話したところ、そもそもOS標準でどう処理しているか分からんことには……という話になったので、改めて調べてみました。

[追記] de:code

先日行われたde:codeのセッション「既存デスクトップアプリの最新OSへの対応」の録画が公開されてますが、この中で高DPI対応の説明があるので(21~45分頃)、参考までに。
1. 実装上の課題

初めに、Per-Monitor DPIを実装しようとすると、大まかに2つの課題があります。
  1. ウィンドウをどのタイミングで、画面上のどの位置になるようリサイズすればいいか。
  2. ウィンドウのサイズが狂うのをどう抑えるか。
1番目は、ウィンドウをリサイズする際、その位置によってはそのウィンドウの属するモニター(重なりが一番大きいモニター)が移動元のモニターに戻ってしまい、結果的にリサイズが繰り返される現象に対するもので、2番目は、リサイズがうまく行かずサイズが狂っていってしまう問題に対するものです。WM_DPICHANGEDが来たときに単純にスケーリングをかけるだけでは問題なしとは行かないんですよね。

2. WM_DPICHANGEDのlParam

この1番目の課題については引っ掛かっていたことがあって、WM_DPICHANGEDのlParamについて、これはWin32のRECT構造体で"a RECT structure that provides the size and position of the suggested window, scaled for the new DPI"とだけ説明があり、新しいDPIでのウィンドウの位置とサイズを表す四角形らしいのですが、実際に試してみると同じようにウィンドウを動かしてもその度に違った値が来るので、意味が分からず無視してました。

それが、改めてOS標準の処理である、Per-Monitor DPIに非対応でDPI仮想化されたウィンドウの挙動を見ているうちに気づいたことがあったので、改めてlParamを確認してようやく理解しました。

結論から言うと、この値はウィンドウをドラッグしているときのカーソルの位置と連動しています。

正直「何だそりゃ」という感じですが、ひとまずこの確認のためのテストアプリは以下のようなもの。
  • 左側はウィンドウの現在の状態で、ウィンドウが移動されるかリサイズされる度に更新されます。"DPI X"はこのウィンドウが属するモニターのPer-Monitor DPI。
  • 右側は最新のWM_DPICHANGEDの情報で、上にwParamに含まれるDPIのXとY、下にlParamに含まれるRECT構造体の位置とサイズをそれぞれ"Suggested Position"と"Suggested Size"として表示します。
  • このアプリはマニフェストファイルでPer-Monitor DPI対応を宣言する一方、リサイズ機能はないので、常に同じサイズで表示されます。
では、1番目に左側のDPI 120のモニターから右側のDPI 96のモニターへ、タイトルバーの左端にカーソルを置いてドラッグした場合。ウィンドウはWM_DPICHANGEDが来た位置で止めています。
  • まずサイズについて、右の"Suggested Size"の432x176は左の"Current Size"の540x220を丁度120から96への比率である0.8倍に縮小した値になっています。これは予想どおり。
  • 次に位置について、"Suggested Position"で示された位置に"Suggested Size"のサイズで描いたものが赤枠の部分です。このときのカーソル位置が赤丸です。赤枠は概ねウィンドウの左上角を固定して縮小していますが、わずかに右に寄っていてカーソルを中心に縮小していることを示しています。
  • 最後にWM_DPICHANGEDが来たタイミングについて、ウィンドウが中央の境界から大きく右寄りに入った後になって来ています。これには意味があって、ウィンドウと赤枠の相対位置はカーソル位置とサイズによって固定されているとして、この赤枠の中心が中央の境界から右側に入ったばかりの位置になっています(境界のX座標の1680に対して赤枠の中心のX座標は1681)。つまり、この赤枠どおりにウィンドウをリサイズしても属するモニターが左側に戻ってしまわない位置というわけで、そうなるようOSがWM_DPICHANGEDを出すタイミングを計っていることを示唆しています。
2番目に、カーソル位置は左端のまま逆方向にドラッグした場合。
  • サイズはDPIの比率と同じく1.25倍になっています。
  • 位置は赤枠がウィンドウよりわずかに左に寄っているとおり、これもカーソルの赤丸を中心に拡大しています。
  • WM_DPICHANGEDが来たタイミングは、今度は中央の境界から大きく左寄りに入った後になって来ています。赤枠のとおりにリサイズすると大きく右側に膨らむわけですが、そうしても属するモニターが右側に戻ってしまわない位置になっています(境界のX座標の1680に対して赤枠の中心のX座標は1679.5)。
3番目に、タイトルバーの中心にカーソルを置いてDPI 120からDPI 96にドラッグした場合。
  • 赤枠はカーソル位置を中心に縮小していることが一目瞭然。
  • WM_DPICHANGEDが来たタイミングは、これも赤枠の中心が中央の境界を越えたとき(境界のX座標の1680に対して赤枠の中心のX座標は1681)。
4番目に、この逆の場合。
  • WM_DPICHANGEDが来たタイミングは、これも赤枠の中心が中央の境界を越えたとき(境界のX座標の1680に対して赤枠の中心のX座標は1679.5)。
5番目に、タイトルバーの右端にカーソルを置いてDPI 120からDPI 96にドラッグした場合。
  • 赤枠は右上角を固定して縮小していますが、これは丸めの問題だと思います。ウィンドウと右上角が重なって見えますが、わずかに左側にずれているので(ウィンドウ右端のX座標の1951に対して赤枠右端のX座標は1949)、カーソル位置を中心に縮小しています。
  • WM_DPICHANGEDが来たタイミングは一見妙で、赤枠の位置からすればもっとウィンドウが左側にあった段階で出せたはずです。一方、これは丁度ウィンドウの中心が中央の境界を越えたときに当たり(境界のX座標の1680に対してウィンドウの中心のX座標は1681)、したがってこのウィンドウが属するモニターが右側に移ったときであることを考えると、WM_DPICHANGEDのアルゴリズムはウィンドウの属するモニターが変わったときに準備に入り、リサイズ後のウィンドウが移動先のモニターに属する位置になったときに発出される、少なくとも2段階になっているのではないかと推測できます。
6番目に、この逆の場合。
  • 赤枠はカーソル位置を中心に拡大しています。
  • WM_DPICHANGEDが来たタイミングは、ウィンドウの中心が中央の境界に重なったときで、左の"DPI X"が120になっていることが示すようにウィンドウの属するモニターが左側に移ったときに当たります。これはアルゴリズムが2段階あるという推測を裏付けるものだと思います。
これでウィンドウを移動させたときについては把握できたと思いますが、ウィンドウのリサイズによって属するモニターが変わったときにどうなるかというと、右側に伸ばした場合が7番目、左側に縮めた場合が8番目。
  • リサイズでモニターが変わった場合、サイズも位置も元と同じものが通知されます(DPIの方だけ変化)。これはOS標準のエクスプローラも同じ挙動なので、ユーザーがウィンドウをリサイズしている最中に自動的にリサイズする必要はないという考え方なのだろうと思います。
最後にウィンドウが静止している状態でディスプレイ設定でDPIを変えたときを確認すると、96から120に変えた場合が9番目、120から96に変えた場合が10番目。
  • 赤枠は単純に左上角を固定して拡大、縮小しています。このリサイズで属するモニターが変わるような位置にウィンドウがあった場合にはさらに何かあるのかもしれませんが、とりあえず。
以上をまとめると、WM_DPICHANGEDのlParamは、
  • ウィンドウをドラッグしてモニター間を移動させたときは、カーソル位置を中心としてリサイズし、リサイズしても元のモニターに戻らない位置の四角形を示す。
  • ウィンドウをリサイズして属するモニターを変えたときは、元のウィンドウと同じ四角形を示す。
  • ディスプレイ設定でDPIを変えたときは、左上角を固定してリサイズした四角形を示す。
ということになります。Microsoftにはしっかりドキュメント化してくれよと言いたいところ。

3. Microsoftの導き

ここまで見ると「実はWM_DPICHANGEDのlParamのとおりにスケーリングすればいいんじゃないの?」と考えるのは自然で、

信じる者は救われる

というか、Microsoft自身のサンプルがそうなっています。
このサンプルの実体部分はC++ですが、ウィンドウのリサイズはこうなっています。
IntPtr PerMonitorDPIWindow::HandleMessages(IntPtr hwnd, int msg, IntPtr wParam, IntPtr lParam, bool% )
{
double oldDpi;
switch (msg)
    {
    case WM_DPICHANGED:
    LPRECT lprNewRect = (LPRECT)lParam.ToPointer();
    SetWindowPos(static_cast<HWND>(hwnd.ToPointer()), 0, lprNewRect->left, lprNewRect-
        >top, lprNewRect->right - lprNewRect->left, lprNewRect->bottom - lprNewRect->top, 
       SWP_NOZORDER | SWP_NOOWNERZORDER | SWP_NOACTIVATE);
    oldDpi = m_currentDPI;
    m_currentDPI = static_cast<int>(LOWORD(wParam.ToPointer()));
    if (oldDpi != m_currentDPI) 
        {
        OnDPIChanged();
        }
    break;
    }
return IntPtr::Zero;
}
これはWM_DPICHANGEDからlParamを取り出して、ノータイムでそのままSetWindowPos関数に入れてウィンドウの位置とサイズを設定しています。

「もうこれでいいかな……」と思ったりもするわけですが、

ところが、ぎっちょん!

このサンプルを実行してみると、モニター間を動かすうちにウィンドウのサイズがどんどん狂っていきます。初めに挙げた課題の2番目の話になりますが、サイズの狂いに脆弱な感じです。

では手を加えるかと思っても、既にアプリのコードとしてはほぼ最短の処理になっているので、この方法のままでは望み薄のような……。

またUIの観点からは、カーソル位置を中心に自分で計算してリサイズするものを試してみましたが、ウィンドウが飛ぶ印象が強いです。そもそもカーソル位置を中心にリサイズするようにしているのは、ドラッグ中に縮小したときにカーソルがウィンドウから外に出てしまう(注:この状態でもドラッグは継続する)ことを避ける狙いがあるのではないかと思いますが、ドラッグ中にカーソルを見ているわけでもなし、むしろウィンドウ位置が飛んでしまうデメリットがあるわけで、個人的にはベストのやり方とは思えないこともあります。

4. 実装

では結局どうするかというと、1番目の課題については以下のようにしました。
  • ウィンドウをドラッグしてモニター間を移動させたときは、リサイズは左上角を固定して行うものとし、そのタイミングはOS標準と同じく、リサイズしても大丈夫な位置にウィンドウが来るのを待って実行する(前に考えた遅延型と同じ)。
  • ウィンドウをリサイズして属するモニターが変わったときは、OS標準に従う(内部のスケーリングだけ行う)。
  • ウィンドウが静止中にDPIが変わったときは、OS標準に従う(どうせなのでWM_DPICHANGEDのlParamを利用する)。
2番目の課題については、色々試しましたが、どうも原因が絞り込めませんでした。現象としてははっきりしていて、ドラッグ中の忙しいときにリサイズすると設定どおりに描画されず、そのままスルーされることがある、というものです。これを確実に避けるにはドラッグ終了後にリサイズすればいいのですが、それも面白くないので試行錯誤しましたが、確実に抑え込める方法は分かりませんでした。

そこで次善の策として、ドラッグ開始時にウィンドウのサイズを内部的に記録しておき、ドラッグ中はその値をベースにリサイズの計算をし(ドラッグ中のウィンドウのサイズは信用しない)、最後の砦としてドラッグ終了後にもう一度リサイズ処理を行う(既に正常にリサイズされていれば何も変わらない)ことにしました。なお、リサイズしても大丈夫な位置までウィンドウが移動されなかった場合は、次の移動の機会に処理を継続します。

コーディングに当たっては、先達の実装例を参考にさせていただきました。
とくにぐらばくさんのDpi構造体は秀逸なアイデアだと思ったので、取り入れさせていただきました。

ということで、自分の実装は以下のとおりです。

[追記] 静止状態でのDPI変更

ウィンドウが静止している状態でディスプレイ設定でDPIを変えた場合(9番目と10番目)について、上記はシステムDPIが96の状態でPer-Monitor DPIを変更した結果でしたが、今更ながらシステムDPIが120の状態では違ってました。

まずシステムDPIが120の状態で(OSの起動時のDPIが120)、DPIを120から96に下げた結果を11番目として。
  • これは10番目に対応しますが、10番目ではlParamの示すサイズはDPIを下げた分だけ縮小されてましたが(元の80%)、この11番目では元のサイズのままです。
次にこの状態からDPIを120に戻した結果が以下の12番目。
  • これは9番目に対応しますが、9番目ではlParamの示すサイズはDPIを上げた分だけ拡大されてましたが(元の125%)、この12番目では元の約156%になっています。
これらの数字がどうして出てきたかは前後のDPIなど関係する数字から計算すれば分かるだろうと思いますが、それぐらいなら初めから自分で計算した方が早いんですよね。

ということで、静止中にDPIが変わったときはlParamをそのまま使ってもいいかと思ってましたが、やはり他の場合と同じく自分で計算した方がいいようです。

0 コメント :