这儿的Linux虽然指代GNU操作系统(由于顺应大众的认知).由于AOSP这个Linuxsystem的桌面挺好,但是BSD(和其它UNIX系统)跑GNUuserland也是一样
我之前写过一篇关于这个的回答,但想详尽讲一下:
这篇文章的存在就是说为何GNU的桌面存在好多好多影响使用和须要解决的问题,例如在GNU/Linux上玩游戏,看视频,在几年前都是一件很麻烦到几乎不可能有好的体验的事情.现今GNU/Linux系统早已在个人市场上早已极为普及(例如steamdeck上的SteamOS和ChromeBook的ChromeOS)
首先这件事情须要从UNIX系统的显示服务器(displayserver)和合成器(compositor)说起.
UNIX界的显示服务器就只有古老的X窗口系统和wayland两个.其中X窗口系统在1984年发布,在那时UNIX小型机器都是小型机中心里的UNIX机器分配给好多人使用,所以X的设计是将服务端(X服务器)和显示端分离,中间使用网路合同.而且X被设计成极易扩充.
这个本意是好的,并且如今不是了:现今的笔记本有GPU来处理渲染,显示服务器和顾客端是一台设备,字体渲染早已独立了,但是桌面有了动漫,屏幕座标和窗口本地座标前馈,高DPI显示...并且X服务器没有变,造成这种问题都是扩充解决:
最后的结果就是原本在X窗口系统中间的X服务器哪些也干不了.由于在现今的桌面下,这种东西都被剥离出了X本身(还有模式设置,被分担给了内核),造成中间的Xserver基本上就是看一眼数据之后直接递献给别的插件linux环境变量,然后递回去,在递给别的.
举个反例,如果你有个硬件渲染的应用,X显示服务器的处理步骤如下:
应用通过图形API/硬件加速完成渲染后把位图存在缓冲区里X服务器通过Damage插件通知合成器插件告诉那里须要更新合成器找到须要重新更新的地方并计划更新合成器通过XComposite扩充来获得应用的位图合成器混和位图到OpenGL材质中合成器通过GLX渲染材质之后贴到合成窗口中X服务器通过内核设置的模式展示渲染完的结果.
其中每一步都是牵涉到X服务器和插件之间的交流,虽然都是没有必要的,尤其是在全屏下:由于一个全屏的应用只须要把第一步的位图直接通过内核设置显示下来就行了.和X之间的交流会造成延后非常大,但是会让垂直同步十分高昂,由于每一步都要贴合显示器的刷新率,且屏幕刷新时间这个参数在部份插件是不敏感的(这也就直接造成了X窗口系统压根难以支持任何真正意义上的随游戏调整的可变刷新率,例如freesync).这种进程间的沟通,因为垂直同步的存在,假如没有在屏幕刷新前完成,这么就要等待到下一个刷新的时侯.所以在X窗口系统下,程序根本没有能力达到相当高的刷新率,但是这并不是就能通过堆叠硬件来解决的(由于延后多为显存信噪比和显存拷贝的困局).但是这样须要应用勾画并递交自己的位图时做一次垂直同步,X窗口系统通过插件合成时再次进行垂直同步,总共两次垂直同步.
但是,这种事情达到的前提是须要X服务器和显示端在一个化学硬件下才可以在合成时使用GPU进行图形API的加速,所以起初设计的X服务器和显示端分离也和小型机的消失步入了历史.
X显示服务器还有很大的问题,它本身没有一个统一的插口来处理跨显示器的高DPI内容,在windows下,程序通过SetProcessDpiAwareness来告诉系统自己支持哪些样的高DPI,在应用申明支持多显示器缩放后联通到DPI不同的显示器后,Windows通过WM_DPICHANGED来通知应用依据正确的DPI重新勾画窗口.这样应用总可以在不同DPI的显示器下正确的以1:1的帧率勾画窗口,但是支持任意的缩放比列.
然而X只能以整数来缩放,在不同的显示器配置下,是靠缩小渲染的画面解决.例如一个2K屏幕决定要125%缩放,这么Xrandr就是以两倍缩放勾画(2560x1440)*2/1.25=(4096x2304)的帧率,之后把整个勾画的结果缩小到2K再显示.更惊悚的是,多显示器的不同缩放比列要根据比列的公倍数进行渲染.这会造成原本就差的性能雪上加霜,而且在电脑笔记本上及其卡顿,让多显示器不同缩放比列基本不现实.
还有安全性,在X会话下,屏保程序没有特权,它只能以普通的应用一样的权限显示一个描边,把屏幕挡住.倘若这期间屏保程序崩溃了,描边消失,恭喜你你的笔记本现今解锁了,所有人都可以查看你的笔记本.(之前cinnamon桌面环境出过一个bug:乱敲鼠标能顿时解锁笔记本,由于碰巧打出了非ASCII字符造成屏保程序崩溃的bug)
还有HDR和10bit的问题,几乎所有桌面环境都不支持10bit输出.由于它们被X服务器限制.目前只有KDE和GNOME两大桌面环境支持低于10bit的输出(都是通过wayland实现的),KDE还是刚才(5.24)支持的.没有10bit意味着HDR显得不可能,例如看手机拍摄和看在线HDR视频的话,只能用KDE和GNOME了(你俩的事情我接出来吐槽)
之后,社区出现了Wayland这个显示服务器,它支持在任意的DPI下以任意的刷新率显示任意色深和色调空间的内容,但是解决了X的服务端和显示端分离的问题,但是剿灭了将渲染的位图传来传去造成的额外开支,彻底前馈了化学象素和逻辑象素.并且这牵涉到整个UI框架和窗口合成器的重画.
大部份的桌面环境不支持wayland,目前流行的桌面环境只有KDE和GNOME支持.并且KDE本身虽然使用wayland会话也要依赖X显示服务器,但是KWin(KDE的窗口合成器)目前并没有使用wayland的全部特点.只剩下GNOME了.
然而wayland的是配挪到了UI框架和应用身上.目前QT和GTK都适配了,而且Java的UI框架没有.而且假如应用自己递交位图,须要自行解决(这就是为何electron/chromium的wayland适配如此慢).如果没有适配,这么就和windows上不支持高帧率的屏幕一样,会变糊,同时实现原理是每位应用跑一个X兼容层,通过兼容层后勾画再交给wayland合成.的确比纯X会话好,但好的有限,而且难以使用wayland的特点,本质上还是被X限制.
如今适配wayland的应用不多,但是好多存在种种问题,例如输入法候选没有出现在正确的位置,窗口边栏没了,键盘大小不对(出现在QT应用中.)这种情况的出现都是wayland本身对那些没有标准,标准是应用框架和桌面环境自己制订的.例如键盘大小,GTK是靠GNOME的设置,而QT是靠XCURSOR_SIZE这个变量查看.造成GNOME下设置的键盘大小在QTwayland应用下不变,键盘大小会在联通进应用后忽然变化.QT觉得这并不是BUG,由于XCURSOR_SIZE是事实下的键盘大小,只不过GNOME没有更改而以.
这些分裂也出现在输入法上.GNU操作系统有好多输入法框架,其中ibus和fcitx5占主流,并且输入法框架须要显示服务器和UI框架适配.诸如在ibus下,要装ibus-gtk3获得GTK3框架支持,ibus-qt获得QT支持.每位UI框架和每位显示服务器的搭配都要装一个库...输入法和UI框架是要配合的...倘若应用没有通过UI框架或则自行适配输入法,这么你在输入时输入法不会弹出来...这就是QTwayland下输入法的问题,它没有更新文字输入的位置造成输入框永远逗留到你第一次输入的位置
窗口边栏也是桌面环境独立的,还有通知和状态栏的后台也是要适配桌面系统的(例如telegram在GNOME下不会在状态栏显示后台,由于它用的是KStatusNotifierItem).这种桌面环境造成的混乱也是制约GNU桌面系统的一大诱因.
emmm,里面的假说都是你在用GNOME和KDE,它们(尤其是GNOME,由于大几率你也用,大部份发行版预装)是最成熟的DE了.至于Xfce,LXDE,LXQT,DeepinDE,Mate哪些的,别想了,部份甚至高DPI都没有适配利索,基本上在现代电脑上,这种DE由于自身和X显示服务器未能完全发挥你的硬件:低端电脑和4K屏幕压根无法用,刷新率固定,没有HDR,达不到高刷新率.emmmlevel-128不想批评大家,由于大家不值得批评.但总规大部份作者都是在课余岁月把这种当成爱好,才让那些桌面系统得以持续,从这个角度早已不错了.虽然windowsvista早已使用合成桌面,这点早已比X显示服务器中级好多了,而且vista早已快16年了,放在如今不仅GNOME和KDE以外,都随意暴打剩下的桌面环境,vista还有使用高效的多的图形API进行合成...
所以话说回去puppy linux,GNU/Linux桌面怎样样,取决于DE由于不仅GNOME都很菜,所以几年前几乎完全不能用,到目前很差linux系统双显示器设置,去年年年末根据roadmap看,那时还勉强可以接受,不晓得今年怎样样linux系统双显示器设置,待会儿就等的不是软件本身的特点支持,而是可以到第二步:生态的支持和解决碎片化的问题了.
参考似乎是GPGPU