アカウント名:
パスワード:
高解像度ディスプレイ ＆ デュアルディスプレイが一部のユーザーに普及していくにつれて、
もうすぐ13インチでフルHD液晶なんてのが出たりして。
開発ツールレベルでは、Windows Forms や WPF では自動スケーリングによる DPI 追従は普通に組み込まれていて、わざわざ無効にしない限り標準で有効になっていますよ。
基本が文字サイズ追従での自動スケーリングであるため、96dpi から 192dpi に変更すると、全コントロールが自動的に 4 倍 (縦横 2 倍) の大きさに変更されます。
Windows Forms では座標系が int でしたが WPF では double になるなどの変化もあったりします。
ただ、やっぱり画像周りがネックで、これはピクセル単位での処理が多いのですよね……。この辺りも画像をコントロールに自動的にフィットさせて表示させる程度の単純な処理であれば自動スケールされますが、そんな単純 (で重い) 処理ばかりで ok という場面は少ないので、アプリ側の作りこみ次第ですね。
なお、この手の機構は一応 MFC レベルでもあったりしますので、無意識にピクセル単位で処理しているとか、96dpi 前提で作られているといった事がなければ、結構動いたりしますよ。
そこでの最大の問題が「ぼやける」「ジャギーが目立つ」事ですね。なので、PC 向けで気軽にやっていいものかは微妙だと思いますよ。
# ディスプレイが高解像度じゃないものが多いが為に、逆にそんな感じでもあるという気もしますが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家
そもそも2Dの能力は十分だったのか？ (スコア:3, 興味深い)
高解像度ディスプレイ ＆ デュアルディスプレイが一部のユーザーに普及していくにつれて、
そのあまりの解像度の高さに2Dの能力不足が再び見え始めています。
GPUの能力的にもインターフェースの転送速度的にも。
1680*1050 1枚ぐらいだと一世代前のオンボードグラフィックチップが悲鳴を上げる程度ですが、
1920*1200 2枚とかになると昔ウィンドウがモタモタしていた頃の気分が味わえること請け合いです。
2D表示はクロック速度依存と言われるので、3Dとはアプローチが違う所が苦しそうですが、
これを隠蔽できるほどに一気に3Dのユーザーインターフェースが広まってしまうかどうかは気になります。
=-=-= The Inelegance（無粋な人） =-=-=
Re: (スコア:1)
高解像度・マルチディスプレーが「一部の」ユーザに使われているのはわかるのですが、これが一般化するのかどうかはかなり疑問。
そもそもこの狭い日本、家庭内にも職場にも、マルチディスプレーを置くスペースなんて、あるんかなぁ。すくなくともわが家にはないなぁ。大型薄型テレビでさえ躊躇しているレベル。
しかも最近の若い人は携帯のあの狭い画面で満足しているようにも見えるし。
特殊目的なら行く所まで行ってくれ、と思うが、今のようなレミング大行進がつづくようには思えない。。。
Re: (スコア:1, すばらしい洞察)
たとえば昔は携帯も2インチで140x200ピクセルだったのが、今は同じくらいの大きさでVGAになってるみたく。
もうすぐ13インチでフルHD液晶なんてのが出たりして。
解像度非依存UIにOSが追いついてないのが問題だなあ。（Mac OS Xは対応してるけど非公式だし、動かないソフトあるし）
Re: (スコア:1)
これからどんどん老眼になっていく私のような人間には、ついていけない、、、
でもね、これから高齢化社会。老眼の方がマジョリティになるのだよ、きっと、、、
#そうなったら、head-mount display かなぁ、、、
Re: (スコア:2, すばらしい洞察)
Clear Type技術を使わずに本当になめらかな文字や画像を表示するためにも使えるのです。
この為にはOS側に相当大掛かりな変更をほどこす必要があるでしょうし、
仮に今の4倍角にしたとするとあらゆる部分の処理が単純に4倍程膨れ上がることになるので、
おいそれと出来る訳ではありませんけどね。
従来の画像等にはフラグでも付けて単純に4倍表示すれば、一応互換性も保てるでしょう。
まあ、いずれなったらいいなぁ的世界です。
=-=-= The Inelegance（無粋な人） =-=-=
Re: (スコア:3, 参考になる)
Windowsは3.0とかそういった時代からずっとGUIの大きさを抽象単位で内部保持しています。
ただ、多くのアプリケーションがおおよそ96dpi程度を想定してドットに依存した設計をしてしまっています。
画面のプロパティーでDPIの設定を変えられますが、うかつに設定を変えるとレイアウトが崩れて使い物にならなくなるアプリケーションがはびこっています。
ファイルマネージャはDPIにスケーラブルでしたが、Explorerはアイコンのバランスが崩れてしまいます。
アクセサリの電卓などは、DPIの設定を大きくすればそれにあわせて大きく表示されます。
抽象単位で実装するより、DPIを固定
Re: (スコア:2, 参考になる)
それまでのWindowsCE は解像度320x240が基本でしたが、WM5では640x480になりました。
WM5で既存のアプリケーションを実行した場合、そのまま表示すると、画面の1/4に小さく表示されることになっちゃいますので、OS側の細工として
・グラフィック描画の単位系をピクセル単位で指定したつもりでも、内部で2倍に変換される(画像などを表示させると二倍に拡大)
・文字描画APIを実行した場合、座標指定単位は荒くなるが、描画内容は高解像度になる
ようになってます。
おかげで、旧OS用のアプリケーションでも、文字主体のものであれば見た目はそのまま高画質化します。
Re: (スコア:1)
開発ツールレベルでは、Windows Forms や WPF では自動スケーリングによる DPI 追従は普通に組み込まれていて、わざわざ無効にしない限り標準で有効になっていますよ。
基本が文字サイズ追従での自動スケーリングであるため、96dpi から 192dpi に変更すると、全コントロールが自動的に 4 倍 (縦横 2 倍) の大きさに変更されます。
Windows Forms では座標系が int でしたが WPF では double になるなどの変化もあったりします。
ただ、やっぱり画像周りがネックで、これはピクセル単位での処理が多いのですよね……。この辺りも画像をコントロールに自動的にフィットさせて表示させる程度の単純な処理であれば自動スケールされますが、そんな単純 (で重い) 処理ばかりで ok という場面は少ないので、アプリ側の作りこみ次第ですね。
なお、この手の機構は一応 MFC レベルでもあったりしますので、無意識にピクセル単位で処理しているとか、96dpi 前提で作られているといった事がなければ、結構動いたりしますよ。
Re: (スコア:1)
> ただ、やっぱり画像周りがネックで、これはピクセル単位での処理が多いのですよね……。
ここでして。
StretchBltだけじゃなく、拡大縮小機能が無いはずのBitBltなどでも拡大処理が行われるので、
「ピクセル単位で処理」して画像を表示するようなコードでも、ちゃんと拡大表示されるんです。
Re:そもそも2Dの能力は十分だったのか？ (スコア:1)
そこでの最大の問題が「ぼやける」「ジャギーが目立つ」事ですね。なので、PC 向けで気軽にやっていいものかは微妙だと思いますよ。
# ディスプレイが高解像度じゃないものが多いが為に、逆にそんな感じでもあるという気もしますが。