实践是验证真理的唯一标准，本文谢绝嘴炮观看及评论。
我只分享几个glmark2的测试结果截图，不评论。最初想分享录屏的，后发现边测边录屏会严重影响评测结果，所以只有截图。
测试工具都是glmark2-es2-wayland，所有的桌面都是在VF2-2311工程版（TF卡，无魔改）上，通过gdm3进入的。有兴趣的可以自己做测试，以下3个桌面在工程版上都可以安装的。
1、Gnome43桌面截图
2、Sway桌面截图
3、Weston 10 截图
其实还有一组把工程版升级到debian-12后的截图，可惜我忘了保留就重新烧录TF。测试的结果：Gnome43也是500左右，Sway、Weston、Wayfire、Labwc都上700，最高接近750。
看来这位作者没有搞懂桌面运行的机制。
先不讨论 2022 年发布的 gnome43 问题。
“桌面系统”和“合成器”的本质区别是前者是一整套的应用环境。而后者仅仅是一个定位为后台运行的服务。
而 gnome 的合成器叫做 mutter 。作者其实是想跑 mutter 和其他合成器的性能对比。
但是，其实这种跑分根本没意义。
因为合成器有自己的功能和定位考虑，某些合成器，会因为处理其他的问题，而拖慢了合成最终图像的效率。
毕竟超高 fps 没有意义，显示器刷心率根本没那么高。甚至可以开垂直同步进一步压低 fps （当然，当初 gl 跑分真的爆出过这种问题，不管怎么优化，就 60fps ）。尤其是 Linux 一直不考虑游戏性能问题，很多开发人员并不考虑应用程序的 fps 问题。
而且，这些合成器，现在有些甚至还支持插件，调用插件进行各种内容的处理，这都会进一步降低合成的性能。
另外，合成器本身还会占用显卡的运行资源。合成器本身如果渲染窗口的一些附加内容，比如阴影，都会一样去调用 3D 计算的硬件。
更不用说，全功能 DE 还会后端启动大量的服务程序。
所以很多人当初都是装个 KDE 或者 GNOME ，但是又同时改用 LXDE、Cinnamon 等等桌面环境作为 session 进程，其实就是为了躲开这些负担因素。
另外，软件的 fps 其实也有自己的机制问题。
有些软件，会去检测“不上屏”性能，也就是不管渲染如何，自己就是不停的进行图形渲染。有些软件会进行“上屏”这个过程因为需要经过到合成器到显卡的效率，这就不光是自己的性能表现问题了。
最后，还有软件兼容问题。某些软件因为人为编写的因素，会选择性的进行某些函数调用。但是因为兼容问题，这些函数可能存在因为兼容问题而进入很多额外调用导致缓慢的问题。
比如因为调用机制不一样，要多进行一次帧图像的复制工作。而内存复制操作看似很快，但是因为每次都要进行复制，fps 越高负担就越重。而因为不兼容问题，这种复制跨函数库或者进程本来有个更快的方案无法使用，软件就会被迫进入一个慢速传递的模式保证运行。而且这部是 bug ，因为有些系统真的就不支持快速的方案。
但是这种内存复制，看似是负担，但是却又能显著的保证系统安全。如果直接发送内存地址给目标，有可能会出现内存空间被同时读写的问题。进而可能导致内存数据错误而让软件崩溃。
所以，综上所说，跑分其实是一个异常复杂的事情。大家使用 Linux ，应该摈弃 Windows 下面那种“没得选所以只能这样的想法”。
本身 Linux 是一个更能让大家学习一个操作系统到底是如何组成的，每个程序之间是如何交互的，为什么一个功能其实有很多种方法，为什么有些方法更快，但是有些方法更可靠。为什么大家要这么选择，或者那么选择。
千万不能带入 Windows 下面那种整个系统就是一个整体不可分的思想，因为某些结果不一样，那就肯定是 XXX 有错误。也千万别认为自己用了 Linux 所以自己就很技术了，毕竟 Linux 仅仅是一个内核，根本不是一个操作系统。
PS：今天在 phoronix 上看到 Linus 又开始喷人的文章，很有收获。换个算法，虽然结果不一样了，但是复杂度显著降低。而结果的差异性，其实只是个可控的常数。
