- 积分
- 212
- 最后登录
- 2022-5-14
- 精华
- 0
- 阅读权限
- 30
- 主题
- 4
- UID
- 2475080
- 帖子
- 530
- PB币
- 576
- 威望
- 0
- 贡献
- 0
- 技术
- 0
- 活跃
- 968
- UID
- 2475080
- 帖子
- 530
- PB币
- 576
- 贡献
- 0
- 技术
- 0
- 活跃
- 968
|
8F
发表于 2016-7-25 03:10:48
IP属地广东
|只看该作者
虽然这是第三方软件的锅,但是很多也是无可奈何。
开发一个高DPI支持的程序也不是那么容易的,.Net方案直接WPF不解释。然而大伙纷纷表示WPF一点也不native,都喜欢搞什么手写win32,DirectUI,于是只能寄望于所用的UI库支持高DPI。
可惜就算是所用的UI库支持,开发这种程序也不是那么容易。就像做一个国际化应用,不能简单的就把阿拉伯语系的文字方向倒过来一样,内容布局也要相应调整。
对高DPI支持的程序来说也是如此,不能说你获取到系统当前是200%缩放你就把4个px当一个来用,那样的结果跟系统的处理方式没有任何区别。文字和图像内容的缩放方式要区分开来,这样却又容易导致在标准DPI下正常的界面在高DPI下不符合设计者意图。(试想下,软件窗口大小不变,里面控件全都变大了,是不是布局就会很奇怪?)
比如“系统设置”窗口,正常情况是网格布局,可当你把窗口缩小到一定大小,就会变成列表布局,所谓响应式布局。
坑有些大,所以很多程序懒得填。为了向下兼容不得不放弃很多新特性。
你们想想看,就连微软官方的各种程序支持高DPI的方式都是直接做一个UWP来取代win32(其实也就是WPF),有些程序甚至都懒得动,可见native想要完美高dpi多麻烦。 |
|