MacOS DPI计算方式 及其和PPI之间的关系

ghgfhghj

不考虑视距算ppi毫无意义

ysc3839

我不了解macOS的情况，提一嘴Windows的情况。
Windows可以看成只有一个“缩放比例”，系统API获取到的都是整数的DPI数值，缩放比例为1时DPI是96，你可以忽略96这个值，就当它是个基准单位，算的时候用实际获取到的DPI值除以96(准确说是USER_DEFAULT_SCREEN_DPI这个宏)即可。

gnattu

楼主经典先开枪再画个靶子，搞明白了的大道理下面第一条就和苹果文档写的不一样



苹果，或者说macOS，自从有高分辨率渲染机制开始，就不再保证“点”和实际世界中的尺寸的对应关系，换句话说楼主心心念念的教条“1inch就该是1inch”从苹果给Mac增加高分屏的那一刻开始就被苹果放弃了

从实用角度（设计UI/开发程序）来讲，计算DPI也没有任何意义，你要能在何种情况下正确显示你的UI，你就必须直接以点为单位去做而不是去脑补你这一个点可能对应多少个像素并且推算出这个屏幕是多少DPI的。一个点由多少个像素呈现并且最终显示出来的尺寸是用户设置的缩放（UI或者字体）和macOS渲染共同决定的

因此你这个72pt=96px的换算公式也是错的，这只是特定屏幕（甚至不是现在还在卖的任何一款Mac的屏幕）上的换算公式

gnattu

slymitec 发表于 2023-7-2 13:13
关于第一点：这是个人观点我也说了。我主张1英寸就显示为1英寸、1厘米就显示为1厘米。（毕竟厘米和英寸也 ...

所以你的意思就是苹果没有你懂macOS？苹果文档没有你对？我们以后开发程序别听苹果的听你的？

另外你这个72pt=96px的测试方法我也实在是绷不住，字号的pt和macOS屏幕空间的pt还能是一个单位吗？72pt的字号被定义为一个逻辑英尺高，并且一个web document的默认dpi大小是96dpi，所以你会在浏览器中测量得到72pt=96px，但是我必须指出这1pt不是macOS屏幕空间的1pt，这1px也不是实际像素的1px，浏览器里的一切都是虚假的，渲染出来的实际大小和这个数值是不一定相等的

苹果这一整段文档的意思就是告诉你不要去管什么DPI，你只用管pt，pt对了UI就对了，占据多少个像素根本不是作为开发者需要操心的，甚至不是苹果需要操心的，因为现代操作系统有非常复杂的缩放，甚至文字可以相对于UI单独缩放，你设置的16pt字号到底是多少个像素你要一个一个用户问过去吗？不说电脑，现在老年人用手机大家都遇到过，很多老年人视力下降就是要缩放把文字搞得很大，那请问你还要先计算一下dpi，然后给大爷大妈们一个推荐缩放比例？这不是大到看得清就行吗？你硬是要算可以，但是我也说了这种计算毫无实用意义，无论是对于用户而言还是对于开发者而言。

ghgfhghj

slymitec 发表于 2023-7-2 10:32
ppi是屏幕硬件参数 和视距无关

“毕竟31.5寸2160p的138PPI实际上还是存在颗粒感”

wish

太™的专业了，这才是Chiphell - 分享与交流用户体验»社区›讨论区-技术与经验的讨论›电脑讨论(新)

rchbk

太专业了，不管怎么说，要用OSX，至少得4k显示器，2k分辨率是模糊的惨不忍睹。。。

gnattu

slymitec 发表于 2023-7-2 13:39
关于第一点：我重新说一下，这是我个人观点，MacOS就一定对或者合适？它要是什么都合适，连Windows的零头 ...

这根本不是他一定对或者合适的问题，这个是苹果介绍他们高分辨率渲染机制时明确提出点和现实世界的长度脱钩，让开发者们避免形成以前的路径依赖，被你说成是“相信权威而从来不思考”，我要是相信了你的用像素去布局结果用户一改分辨率/缩放/字号UI坏掉了，又或者苹果一拍脑门又出了个新的规格的显示器你来做适配？用点而不是像素的根本原因就是为了让设备和UI设计中的尺寸解耦，不然做适配会做死你

所以即使你拿把尺子量 现在在你的设备上是这个对应关系，以后也不一定会是，你不可能根据你关心的这点“技术细节”来赌苹果会不会做修改。

顺便一提：你设置的字号和你实际的文字大小的“逻辑关系”都不对应。你不信你可以自己测量一下，看看72pt高的文字，是不是真的72pt高

再顺便一提：如果你有条件不变更显示器也不修改缩放（最简单的方法就是都100%）你还用文本编辑器，你调两个72pt字，你看看windows的72pt字和macOS的72pt字是不是一样大呢 如果不一样大那你这个72=96是不是就有问题了呢

算了 我直接给你看吧：



并非没人关心这些技术细节，而是这种技术细节只会增加没有必要的开发成本，我们需要尽力避免基于这些细节去做实际应用。

gnattu

slymitec 发表于 2023-7-2 15:06
就是因为dpi不等于ppi，所以才导致台式机显示器1英寸不是显示1英寸长，1cm不是显示1cm宽。

苹果的显示器 ...

不是 没意思兄弟 就算我把什么都截出来你也可以说我是P图故意缩放了 你可以自己截个图自己对比着看 我看你也不像是连这种对比条件都没有的人

分辨率和缩放都调成一样了按照你的理论那这俩字就应该一样大嘛，但其实他们大小就是不一样
所以你的理论就是不成立的
你有什么个人偏好我不干预，但是就你这个把字号大小对应到DPI在对应到现实空间大小的这一整套逻辑链条在最关键的多少号字该多大的第一环就已经不成立了，更不用提后面和现实空间的大小对应。

要是我说你心心念念的DPI=PPI的在Windows下面的实际显示效果是你看到的东西会比“理论大小”大33%，不知道你现在是个什么心情呢？

gnattu

slymitec 发表于 2023-7-2 15:35
你的
1、屏幕分辨率是3024x1964，这个确认了
2、Windows设置的200%缩放，这个确认了

大家都是200%，72pt字就是可以和72pt字大小不一样，我只能说现代科技不适合楼主这种强迫症，知道越多越痛苦

Ownab

slymitec 发表于 2023-7-2 15:35
你的
1、屏幕分辨率是3024x1964，这个确认了（MBP 14）
2、Windows设置的200%缩放，这个确认了

3不用算, 就是你猜的这个。  mbp就是2x 近几年的iPhone是3x

gnattu

slymitec 发表于 2023-7-2 15:53
3不一定哈，MBP/MBA 13就不是（但是MBP 14/16是，为了绝对保险所以确认一下）

我正在给他处理Windows的 ...

那你又错了
你猜猜在MBP13上按command+shift+3全屏截图出来的那张图的分辨率是多少？

2560x1600？错！是2880x1800
也就是说即使是MBP13的截图，也不会影响结论，因为截图出来的像素会比屏幕实际像素更多（因为实际就是渲染了更多像素）

gnattu

slymitec 发表于 2023-7-2 16:24
哦，那就是截图截的是虚拟分辨率而不是物理分辨率，反倒是不能作为分析宜居路。那楼上那个结论就还是不对 ...

那我能说每一个设备可能都不一样吗

对于实际分辨率和渲染分辨率匹配的显示器，截图出来的分辨率和实际分辨率是一致的，而由于缩放也是整数倍，所以你硬要算是能算出来一个值的

但是存在不匹配的情况（比如MBP13），这个时候渲染出来的东西放到实际屏幕上可能都不能使用完整像素去呈现，因为这种不足2x的缩放实际处理方式是渲染一个2x的分辨率然后往下downsample到屏幕分辨率。那你算出来的带小数点的像素数量实际上不能说明任何东西，因为像素是屏幕的最小单位，而高分辨率downsample到屏幕分辨率来消除不完整的像素是一套单独的渲染流程，具体到丢了什么补了什么得看你显示的是什么字。换句话说非整数倍渲染缩放本来就不可能达到像素级精确，这个时候眼睛能接受是最重要的

gnattu

slymitec 发表于 2023-7-2 16:51
按照楼上的意思，那就是MacOS反而是不遵守标准了，

1in到底多长，不同软件都不一样，都不是显示器不遵守 ...

取决于你如何定义“标准”
Windows和Web的标准中的1逻辑英寸是印刷时代现实英寸的1.33倍，如果你执著的是和现实英寸的对应，那其实windows和web的标准的单位长度和现实比是偏大的，这也是同样字号windows字更大的根本原因

但我不会说这些标准是错的，windows和web提高1.33倍的单位长度就是为了适应显示器上阴间的字体显示（想象一下真的用72dpi的windows的字体会多阴间）但是教条的认为这个单位长度就一定和现实长度有关联，我只能说是一厢情愿，因为这个概念就是从印刷脱胎出来的

至于你说的设置图片大小，我只能说你仿佛完全没有设置过。一个数字格式图片不可能脱离dpi单独设置大小，用于web和用于印刷有截然不同的dpi设定，最终导出相同英寸的图片分辨率并不会相同，而忽略这一点强制设置一个统一DPI本身就会造成大小发生偏差

比如根据印刷传统的72dpi导出10英寸图片，在你钟爱的1:1dpi屏幕在windows下看就会是7.5英寸大小，你还是得给他缩放回去，而在macOS下同样1:1dpi就不需要这一步缩放。而回到实际情况是现在几乎不存在不需要特别缩放的显示器，因为现在印刷也早就不是只有72dpi了