我正在开发适用于Linux和Windows的便携式GUI工具包，并且遇到了一些性能问题。在几个系统上（因为我的上网本基于臭名昭着的英特尔GMA 3650）受到安装的驱动程序的极大影响。
但是什么是悖论，当安装后备VESA驱动程序时，我的代码的性能远高于专用驱动程序。
另一方面，使用专有驱动程序，如预期，计算机的性能非常好。硬件加速工作，高清视频播放没有问题，只有我的代码以这种奇怪的反向方式受到影响。
我的代码使用Xlib，Xft，pthreads等常用库。
Windows端口（使用WinApi）以极快的速度运行，没有任何问题。甚至在葡萄酒中。另一个悖论是，为Windows编译并在WINE中运行的相同程序比Linux编译程序快得多。
造成这种影响的原因是什么，以及在哪里挖掘才能解决问题。
源代码存储库是managed by fossil scm
一个测试示例位于trunk/freshlib/TestFreshLib.fpr（对于普通FASM编译freshlib/test_code0/TestLib.asm）
这是可移植的示例，也可以针对Windows和Linux进行编译。
更新1：经过一番思考和代码探索，我有一个假设。我使用两种不同的方法在窗口上绘制图形：
我正在测试的控件使用双缓冲，其中图像缓冲区是服务器端的像素图。
但是IIRC，Xft在客户端绘制，然后将图像作为位图图像发送到X服务器，而XLib直接在服务器端绘制。
这两种方法之间是否存在冲突（以某种方式与硬件加速连接）会导致性能下降？
答案 0 :(得分：0)
虽然它可以自动执行（Apple使用XQuartz API为此设计了Opencl），但X库并未设计为使用硬件加速。众所周知，OpenGL和directX可以用于3D环境，通常可以在游戏中找到它。
但您也可以将它用于2D。 Direct3D设计用于使用多边形Direct2D用于平板图形。最初，OpenGl旨在保持通用性：因此，您可以使用许多功能来实现硬件加速图形。
主要X11实施包括GLX DRI和Gallium 我从来没有写过使用这些API的东西，但我知道某些程序确实通过这种方式加速了它们的绘制。
使用后备VESA观察到的性能优势可能有以下解释： 专有驱动程序执行额外的检查（例如，查看它是否被要求使用硬件加速;然后因为它是常规Xlib，它不会在大多数时间加速）而后备驱动程序不能使用硬件加速并前进使用CPU代替GPU。