アカウント名:
パスワード:
16:10でしかもRetina解像度なんでWindows PCのメーカーはこれを出せないのか…。
OS側のDPIの扱いもあって仮にWindows機に搭載されてもまともに使えないんじゃないかと。VAIO ZのフルHDですらまともに使うのは簡単じゃないといわれてるぐらいなので。
まともに使えないというか、解像度が広がったらダイアログやウィンドウやボタンのサイズが小さくなってしまうので使いづらくなってしまう…ってのがあるんでしょうね。フォントサイズを変更してもそれに追随しないアプリケーションが多いのも原因でしょうか。(英語フォントから日本語フォントに変更しただけでレイアウトが崩れるアプリケーションが多いこと…)
その辺 Mac (というより cocoa?)は良く出来ているようですね。私は触ったことが無いのでなんとも言えませんが。ちょっとだけ Mac がうらやましくなってしまいます。
Macはあんまり詳しくないですが、iOS機だとRetinaは良いですね。自動的です。ボタンもレイアウトも崩れません。それなのに、画像やボタンなどは自動的に綺麗に表示します。
自前で作った画像ボタンなどで、解像度が足りない(例えばiPhone3ぴったりに作っちゃった)場合は、拡大されてガタガタになります。でも自動的に大きく拡大調整表示されるのでレイアウトは崩れません。解像度が足りてるボタンや画像、ベクタ画像や文字フォントは、きちんと最高の解像度のまま表示されます。Windowsで同じことすると、ボタンが小さく表示されて押せなくなるだけですからね…。
プログラムから見ると座標系が全部仮想になってて、ピクセル指定しても実際は自動的に最適なサイズに変換してるわけです。Windowsだと本当にピクセルになってしまうあたりが違う。
このあたりの問題は、Windows95の96/120DPI切り替えの頃からだから、何年放置してるんでしょうね？Windows7でも解決にはほど遠い感じですが…。
そのあたりの解決を目指したのがXAMLでありWPFなんですが、Metroでようやく実を結ぶかどうか、というところですね。
逆に言えば、それで大して困ってなかったということでもありますが。
> 逆に言えば、それで大して困ってなかったということでもありますが。「メモリ640KBで大して困ってなかった」みたいな本末転倒感。
640kbの壁は困ってる人が多かったからすぐに全力で対処されたでしょ。
「すぐに」？
普通の人が困ったのは、一太郎 [wikipedia.org] の Ver.4 がでた 1989年あたりから。「全力で対処」かどうかは分かりませんが、曲がりなりにも壁が無くなったと言えるのは Windows 95 [wikipedia.org]の 1995年ぐらいか。6年というのは普通「すぐ」とは言わないと思います。
# OS/2 Ver.2？ 記憶にございません
Windows 3.0/3.1 の時代に config.sys/autoexec.bat と取っ組んで 640KB の壁と戦っていました。EMS メモリ [wikipedia.org]と FM 音源とか、PC Card とか、NIC（当然 AUI）とか、ODI ドライバや NDIS ドライバとか、とにかく敵は強大でした。
いやEMSとかLoadHighとかそういうすぐ出来る範囲のアドホックな取り組みでしのいでたのがここで言ってる「すぐ全力で対処」ってやつじゃないのかな？# MS-DOS 5.0Aでは動いてたゲームが6.0に変えたら640kエリアの消費が大きくなって起動しなくなった思い出。。。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
ディスプレイだけほしい (スコア:0)
16:10でしかもRetina解像度
なんでWindows PCのメーカーはこれを出せないのか…。
Re: (スコア:3, おもしろおかしい)
OS側のDPIの扱いもあって仮にWindows機に搭載されてもまともに使えないんじゃないかと。
VAIO ZのフルHDですらまともに使うのは簡単じゃないといわれてるぐらいなので。
Re: (スコア:2)
まともに使えないというか、解像度が広がったらダイアログやウィンドウやボタンのサイズが小さくなってしまうので使いづらくなってしまう…ってのがあるんでしょうね。
フォントサイズを変更してもそれに追随しないアプリケーションが多いのも原因でしょうか。
(英語フォントから日本語フォントに変更しただけでレイアウトが崩れるアプリケーションが多いこと…)
その辺 Mac (というより cocoa?)は良く出来ているようですね。
私は触ったことが無いのでなんとも言えませんが。
ちょっとだけ Mac がうらやましくなってしまいます。
Re: (スコア:1)
Macはあんまり詳しくないですが、iOS機だとRetinaは良いですね。自動的です。
ボタンもレイアウトも崩れません。それなのに、画像やボタンなどは自動的に綺麗に表示します。
自前で作った画像ボタンなどで、解像度が足りない(例えばiPhone3ぴったりに作っちゃった)場合は、拡大されてガタガタになります。
でも自動的に大きく拡大調整表示されるのでレイアウトは崩れません。
解像度が足りてるボタンや画像、ベクタ画像や文字フォントは、きちんと最高の解像度のまま表示されます。
Windowsで同じことすると、ボタンが小さく表示されて押せなくなるだけですからね…。
プログラムから見ると座標系が全部仮想になってて、ピクセル指定しても実際は自動的に最適なサイズに変換してるわけです。
Windowsだと本当にピクセルになってしまうあたりが違う。
このあたりの問題は、Windows95の96/120DPI切り替えの頃からだから、何年放置してるんでしょうね？
Windows7でも解決にはほど遠い感じですが…。
Re: (スコア:0)
そのあたりの解決を目指したのがXAMLでありWPFなんですが、
Metroでようやく実を結ぶかどうか、というところですね。
逆に言えば、それで大して困ってなかったということでもありますが。
Re: (スコア:0)
> 逆に言えば、それで大して困ってなかったということでもありますが。
「メモリ640KBで大して困ってなかった」みたいな本末転倒感。
Re:ディスプレイだけほしい (スコア:0)
640kbの壁は困ってる人が多かったからすぐに全力で対処されたでしょ。
Re:ディスプレイだけほしい (スコア:3)
「すぐに」？
普通の人が困ったのは、一太郎 [wikipedia.org] の Ver.4 がでた 1989年あたりから。「全力で対処」かどうかは分かりませんが、曲がりなりにも壁が無くなったと言えるのは Windows 95 [wikipedia.org]の 1995年ぐらいか。6年というのは普通「すぐ」とは言わないと思います。
# OS/2 Ver.2？ 記憶にございません
Windows 3.0/3.1 の時代に config.sys/autoexec.bat と取っ組んで 640KB の壁と戦っていました。EMS メモリ [wikipedia.org]と FM 音源とか、PC Card とか、NIC（当然 AUI）とか、ODI ドライバや NDIS ドライバとか、とにかく敵は強大でした。
Re: (スコア:0)
いやEMSとかLoadHighとかそういうすぐ出来る範囲のアドホックな取り組みでしのいでたのが
ここで言ってる「すぐ全力で対処」ってやつじゃないのかな？
# MS-DOS 5.0Aでは動いてたゲームが6.0に変えたら640kエリアの消費が大きくなって起動しなくなった思い出。。。