3

我正在开发适用于 Linux 和 Windows 的便携式 GUI 工具包，但遇到了一些性能问题。在几个系统上（如我基于臭名昭著的英特尔 GMA 3650 的上网本）受安装的驱动程序的影响很大。

但矛盾的是，当安装了后备 VESA 驱动程序时，我的代码的性能比使用专用专有驱动程序高得多。

另一方面有了专有驱动，电脑的性能果然非常好。硬件加速有效，高清视频播放没有问题，这样只有我的代码以这种奇怪的反向方式受到影响。

我的代码使用 Xlib、Xft、pthreads 等常用库。

Windows 端口（使用 WinApi）以极快的速度运行，没有任何问题。即使在葡萄酒中。另一个悖论是，为 Windows 编译并在 WINE 中运行的相同程序的绘制速度比 Linux 编译程序快得多。

这种效果的原因可能是什么以及在哪里挖掘以修复它。

源代码存储库由化石 scm 管理

一个测试示例在trunk/freshlib/TestFreshLib.fpr（对于普通的 FASM 编译freshlib/test_code0/TestLib.asm）

这是一个可移植的示例，也可以为 Windows 和 Linux 编译。

更新 1：经过一些思考和代码探索，我有一个假设。我使用两种不同的方法在窗口上绘制图形：

  1. 使用 XLib 绘图函数绘制线条和矩形。
  2. 使用 Xft 库绘制文本。

我正在测试的控件使用双缓冲，其中图像缓冲区是服务器端的像素图。

但是 IIRC，Xft 在客户端绘制，然后将图像作为位图图像发送到 X 服务器，而 XLib 直接在服务器端绘制。

这两种方法之间是否可能存在一些冲突（并以某种方式与硬件加速有关）导致这种性能下降？

4

1 回答 1

0

尽管它可以自动执行（Apple 使用其 XQuartz API 为此目的设计了 Opencl），但 X 库并非旨在使用硬件加速。众所周知，OpenGL 和 directX 可以用于游戏中通常可以找到的 3D 环境。

但您也可以将其用于 2D。Direct3D 旨在使用多边形 Direct2D 用于板图形。一开始，OpenGl 的设计目的是保持通用性：因此您有许多可用于硬件加速图形的功能。

主要的 X11 实现包括 GLX DRI和镓。
我从来没有写过使用这些 API 的东西，但我只知道某些程序确实通过这种方式加速了他们的绘图。

使用后备 VESA 观察到的性能优势可能有以下解释：专有驱动程序执行额外的检查（例如，查看它是否被要求使用硬件加速；然后因为它是常规 Xlib，它大部分时间都不会加速）而后备驱动程序不能使用硬件加速，而是直接使用 CPU 而不是 GPU。

于 2013-10-22T13:35:44.673 回答