我正在为Linux和Windows开发一个可移植的GUI工具包，并且遇到了一些性能问题。 在几个系统（因为我的上网本基于臭名昭着的英特尔GMA 3650）非常高的影响，安装的驱动程序。
但是，如果安装了后备VESA驱动程序，那么这个矛盾是什么？我的代码的性能远高于专用驱动程序的性能。
另一方面，与专有的驱动程序， 如预期的计算机的性能是非常好的。 硬件加速工作，高清video播放没有问题，这种方式只有我的代码是在这种奇怪的反向的方式受到影响。
我的代码使用像Xlib，Xft，pthreads等通用库
Windows端口（使用WinApi）运行速度很快，没有任何问题。 即使在葡萄酒。 作为另一个悖论，为Windows编译并在WINE中运行的相同程序的绘制速度比Linux编译程序快得多。
这可能是造成这种影响的原因，以及为了解决问题而在哪里挖掘。
源代码库由化石scmpipe理
一个testing例子是在trunk/freshlib/TestFreshLib.fpr （对于普通的FASM编译器freshlib/test_code0/TestLib.asm ）
这是便携式的例子，也可以编译Windows和Linux。
更新1：经过一些思考和代码探索，我有一个假设。 我使用两种不同的方法在窗口上绘制graphics：
我正在testing的控件使用双缓冲，其中图像缓冲区是服务器端的像素图。
但是IIRC，Xft在客户端绘制，然后将图像作为位图图像发送到X服务器，而XLib直接在服务器端绘制。
这两种方法之间是否存在某种冲突（以某种方式与硬件加速有关）会导致性能下降？
尽管它可以自动执行（Apple为此目的使用XQuartz API设计了Opencl），但是X库不能用于硬件加速。 OpenGL和DirectX都知道可以在3D游戏中找到它。
但是，你也可以使用它的2D。 Direct3D被设计为使用多边形Direct2D是用于平板图形。 一开始，OpenGl被设计为保持通用目的：所以你有许多功能可以用于硬件加速图形。
主要的X11实现包括GLX DRI和Gallium。
我从来没有写过使用这些API的东西，但是我只知道某些程序通过这种方式加速了他们的绘图。
VESA的性能优势可能会有以下解释：专有驱动程序会执行额外的检查（例如，是否要求使用硬件加速;因为它是常规的Xlib，大多数情况下不会加速）而后备驱动程序不能使用硬件加速，并且不能使用CPU来代替GPU。