sakura
sakura copied to clipboard
sakura-editor
HighDPI対応
HighDPI対応で必要と思われる項目を下記に列挙します。
- [ ] アイコンやカーソル等の画像リソースの高解像度化
- [x] ツールバーのアイコン表示が小さい #631
- [x] メニューのアイコン表示が小さい #631
- [x] メニューのドロップダウンの右向きの▶が表示されない #512
- [x] ルーラーの高さを変えた場合に10文字区切りの見出し文字のフォントが縦長になって見づらいので横幅も伸ばす #505
- [x] バージョン情報画面のアイコンが小さい #517
- [x] タイプ別設定のカラータブの色指定のリストボックスの前景色、背景色を表す矩形の横幅が小さい #499
- [ ] タイプ別設定のカラータブの色指定のリストボックスの左端のチェック ✓
- [x] 共通設定のツールバータブのリストボックスのアイテムに表示しているアイコンが小さい #631
- [x] 共通設定の支援タブのキーワードヘルプのグループボックス内に表示しているフォント選択ボタンの左側に表示しているフォント名の表示が小さい #645
- [ ] ステータスバー上のプログレスバー表示 https://github.com/sakura-editor/sakura/issues/471#issuecomment-443504381
高解像度ディスプレイ対応、いつかはやりたいです。やるのは賛成 :smile:
HighDPIには何段階かのステップがあると思っています。
| ステップ | 内容 |
|---|---|
| 72dpi | 旧世代のディスプレイ解像度。大昔のMacやVisual Basicと互換。 |
| 96dpi | windows 95世代のディスプレイ解像度。モバイルノートなどのディスプレイ解像度として今も現役です。 |
| HighDPI | windows vista世代から登場。いわゆるFull HDディスプレイに対応するための仕組み。旧来のDPIで作られたアプリは実際の解像度に合わせて拡大されるようになった。高DPI対応アプリは自動拡大の対象外でサクラエディタはこれに対応していることになってます。（実は未対応な部分が多いんですが :cry:） |
| HighDPI(PerMonitor) | windows 8.1世代から登場。複数ディスプレイを接続した端末での使い勝手を向上するための仕組み。拡大率をウインドウごとに制御できるようになった。これができると、ノート＋4Kディスプレイなどの組み合わせで使うときも支障なく使えるようになります。「これに対応してほしい」という要望はtwitterや掲示板でよく見かけるので、そのうちやろうと思ってます。 |
フィルタなしの技術情報が欲しい方はこの辺見てください。
この issue で上がってるのは「実は未対応」な部分の洗い出しだと思います。
アイコンサイズは大きくしないといけないと思っています。 大きなビットマップを用意して同梱するのか、今のビットマップをソフトウェア的に拡大するのかは別問題として、対応は必要だと思います。
大きなビットマップを用意する場合、現状の4bit16色ビットマップをそのまま高解像度化でよいのか、ちょっと迷いがあります。wikiにあるようなかっちょいい感じのものと差し替えるべきなんじゃないか、みたいな迷いが。(機構的には8bit256色ビットマップにも対応してるので綺麗なアイコンも可能なんです。)
ちょっと記憶があいまいなんですが、対応OSがwindows7以降なら 32bit(true color+alpha) のアイコンも使えたような気がします。
色深度の話はコレとは別件になると思うんですが、高解像度化に伴って考えないといけない変化の一つにはなってくるように思っています。
ところで、この話の着地点はどの辺になるんでしょう・・・
アイコンサイズは大きくしないといけないと思っています。 大きなビットマップを用意して同梱するのか、今のビットマップをソフトウェア的に拡大するのかは別問題として、対応は必要だと思います。
こちらは自分は両方必要だと思います。小さいサイズのビットマップを引き延ばして表示するとドットが目立ってしまいます。そのまま小さく表示するよりかはマシだと思いますが、やはり大きいアイコンを用意して使いたいですね。
大きいサイズのアイコンも用意してDPIが大きいケースではそれを自動的に使うようにするのか、それともユーザーが設定で任意に選べるようにするべきのどちらが良いのかの判断は付けられないですね。。
大きなビットマップを用意する場合、現状の4bit16色ビットマップをそのまま高解像度化でよいのか、ちょっと迷いがあります。wikiにあるようなかっちょいい感じのものと差し替えるべきなんじゃないか、みたいな迷いが。(機構的には8bit256色ビットマップにも対応してるので綺麗なアイコンも可能なんです。)
お、wiki に色々上がっていたんですね。まぁ綺麗なアイコンを使うのも問題無いと思いますよ。
ちょっと記憶があいまいなんですが、対応OSがwindows7以降なら 32bit(true color+alpha) のアイコンも使えたような気がします。
これについて自分も記憶がはっきりしないのでぐぐってみました。
https://social.msdn.microsoft.com/Forums/en-US/d43eaf45-d5e0-474c-a542-60376d411ffa/drawing-32bit-icon?forum=vcgeneral&forum=vcgeneral
を見てみると、comctl32.dll の 6.0 以降からのサポートみたいですね。
https://www.geoffchappell.com/studies/windows/shell/comctl32/history/index.htm
現在サポート対象の Windows 7 以降のOSであれば大丈夫なようです。
色深度の話はコレとは別件になると思うんですが、高解像度化に伴って考えないといけない変化の一つにはなってくるように思っています。
自分は高解像度化とは切り離しても良いと思います。高解像度対応をしないと出来ない事では無いと思いますし。ついでにやってしまえばという気持ちも分からなくもないですけれど。
ところで、この話の着地点はどの辺になるんでしょう・・・
この Issue に限って言えば冒頭のタスクリストに上げた点には対応したいです。
HighDPI(PerMonitor) に関しては自分はこの Issue では扱わずに対象外にして、まず HighDPI 対応を済ませてからその後に別の Issue を作って対応するのが良いと思います。
フィルタなしの技術情報が欲しい方はこの辺見てください。
リンク先に書いてありますが、PerMonitorには、Win10 1703から使えるようになったPerMonitor v2というものもあります。
リンク先に書いてありますが、PerMonitorには、Win10 1703から使えるようになったPerMonitor v2というものもあります。
説明できる自信がなかったので端折りました :cry:
「拡大率をウインドウごとに制御できるようになった」の説明はV2なんです。 V1は「拡大率をアプリごとに制御できるようになった」でちょっと違うはず。 まずは System DPI に対応させなきゃならんです・・・。
V1は、
- Top-level HWND is notified of DPI change
- No DPI scaling of any UI elements.
V2は、
- Top-level and child HWNDs are notified of DPI change
- Automatic DPI scaling of:
- Non-client area
- Theme-drawn bitmaps in common controls (comctl32 V6)
- Dialogs (CreateDialog*)
ってことで、メニューバーやスクロールバーなどの非クライアントエリアもスケールされるようになったのは良いですね。
自分は 200% (192dpi) で使っていますが、24x24 ドットのアイコンなら入るけど 32x32 ドットのアイコンだとはみ出てしまうぐらいの高さになっています。
クッキリハッキリぎざぎざ表示させる対応なら簡単にできそうです（キリッ
じゃあ @berryzplus さんには以下のページのガイドラインに従った 256x256 サイズのアイコンを用意して頂きましょうか。
https://docs.microsoft.com/en-us/windows/desktop/uxguide/vis-icons
じゃあ @berryzplus さんには以下のページのガイドラインに従った 256x256 サイズのアイコンを用意して頂きましょうか。
https://docs.microsoft.com/en-us/windows/desktop/uxguide/vis-icons
先生！ハードル高すぎます！ｗ
クッキリハッキリぎざぎざってのは単にスケーリングするだけの対応を行う場合の話です。 アイコン読み込み箇所は共通化されているので、そこでsystem dpiに合わせたスケーリングを行えば実現可能と思われます。
色々な設定の単位が ドット なのが少し気になりますね。
将来的に PerMonitor な HighDPI 対応するまでに、 ポイント 等の単位でも設定出来るようにしておくと良いかも知れないですね。
タイトルバーの左端に表示されるアイコンがHighDPI環境でぼやけて表示される件ですが、現在表示しているものよりもっと解像度が高いアイコンは他で使われているので、それを使うのが良さそうです。
「開」「閉」「動」「場」という字の横棒が、モニタのピクセルグリッドに寄せられて等間隔でないのが美しくないですね。ヒンティングはオフの方が好きです。「て」という字の微妙に右上がりの横棒を見るとわかりますが、縦方向のアンチエイリアスが効いているようです。DirectWrite が導入された当初のデフォルトは横方向だけが有効で縦方向はオフでした。そして新しいバージョンの DirectWrite は Vista にバックポートされていません。うらやましい。ゲームができる４Kモニタが欲しい。
ヒンティングはオフの方が好きです。
そこに食いつかれるとは思っても見ませんでした。出してみるものですねｗ
そして新しいバージョンの DirectWrite は Vista にバックポートされていません。
対応OSの話題で vista を外した理由の一つがこれです。 DirectWrite対応はまだまだずっと先の話だと思っていますが。
うらやましい。ゲームができる４Kモニタが欲しい。
実は借り物、明日返却 :sob: 画面小さいのに4Kだから、推奨拡大率250%という無茶な値になってます。 15.4インチUHDのノートパソコンです。
対応OSの話題で vista を外した理由の一つがこれです。
Vista にも DirectWrite はあるんです。ただバージョンが古いために、たとえば Firefox がバージョンアップとともに DirectWrite の新しいバージョンを要求するようになったために、一度 DirectWrite が有効になっていたものが現在はまた GDI で描画されるといった事態になっています。アプリケーションの対応次第なんです。
DirectWrite対応はまだまだずっと先の話だと思っていますが。
マイクロソフトのサンプルを拝借して文字を出すだけならすぐなんですが、終着点は berryzplus さんがどこまでの完成度を追求しているか次第です。
Issue #538 が関係します。それへの対応なしでは描画速度が落ちました。
Issue #588 もやや関係します。速度を求めて描画先を Direct2D サーフェスに切り替えるとなると特殊図形のお絵かきを移植しなければいけません。フォントがあれば文字コードを指定するだけです。
Vim の話
- Color Emoji (DirectX support improvements) by koron · Pull Request #2375 · vim/vim
- カラー絵文字パッチ制作の経緯 — KaoriYa
- Vim の DirectX を速くした話 — KaoriYa
GDI v.s. DirectWrite
カラー絵文字が登場するまでは GDI + ClearType で十分だと思ってたんですよね。
縦方向のアンチエイリアスに注目して曲線部分の輪郭のギザギザを探さなければ違いなんてわかりません。実装がへぼで本領が発揮できていない可能性がなきにしもあらずですが。
HighDPI 対応の話題から外れてしまったのでここまでにしておきます。
メニューのアイコン表示が小さい
CMenuDrawerのリファクタリング試行中です。 辻褄を合わせるためにかなり大きな構造変更をすることになりそうです。
ツールバーのアイコン表示が小さい メニューのアイコン表示が小さい 共通設定のツールバータブのリストボックスのアイテムに表示しているアイコンが小さい
この3つ、もう少し整理したら出せる感じです。 画像ファイル読込み時にサイズをチェックして小さいアイコンだったらStretchBltで引き延ばす、という内容。実際にHighDPI向けの大きなイメージを用意したらそれはそれで動く感じを想定しています。アイコンの拡大はうまくいきそうだけど共通設定「ツールバー」のとこの表示がおかしくなってるのとか、細かいとこの対応中です。
Ctrl キーを押しながらマウスホイールの回転をする事でフォントサイズを変える事が出来ますが、その際にステータスバーの左端にプログレスバーのアニメーション表示が短時間行われます。「こんな表示いるのかよ…」という気がしますがその考えはいったん忘れて、その表示がDPIの変化に対応していない事に気が付きました。
縦幅がピクセル絶対値のようで、高DPIになればなるほどステータスバーの縦幅と比べて相対的に小さく表示されてしまいます。
| スケール | GIF |
|---|---|
| 100% |  |
| 200% |  |
| 300% |  |
「開」「閉」「動」「場」という字の横棒が、モニタのピクセルグリッドに寄せられて等間隔でないのが美しくないですね。ヒンティングはオフの方が好きです。「て」という字の微妙に右上がりの横棒を見るとわかりますが、縦方向のアンチエイリアスが効いているようです。DirectWrite が導入された当初のデフォルトは横方向だけが有効で縦方向はオフでした。そして新しいバージョンの DirectWrite は Vista にバックポートされていません。うらやましい。ゲームができる４Kモニタが欲しい。
https://silight.hatenablog.jp/entry/2017/05/03/144138
https://twitter.com/haijinboys/status/928657251732090880
Windows 10 Creators Update 以降では GDI 描画でも縦方向のアンチエイリアスが効くようになった
ようです。ただ拡大表示するとグラデが段々になっているので処理速度との兼ね合いかもしれませんが品質はそこまで高くないような気がします。実は DirectWrite を使うともっと色々と改善出来るのかもしれませんがよくわかりません。
Windowsはヒンティング有りの文化のようで OS Xはヒンティング無しのようですが昔読んだ話なので今は違うかも？ 8K や 10K 環境が普及したらあまり気にならなくなりそうですね。