为什么 DirectFB 没有在 GNU/Linux 中得到更广泛的应用？是否存在 X11 中不存在的严重限制？
据我了解，DirectFB为多种显卡提供硬件加速。此外，它比 X11 更小、更快，并且占用的内存更少。那么，为什么它没有比现在更主流呢？
我真正不确定的是：常见的 GTK+/Qt 程序是否需要移植到它？在 DirectFB 网站上，有一个将 Firefox 移植到其中的项目。如果 GTK+ 能够直接使用 DirectFB，为什么还需要这样做呢？我（可能是错误的）理解它的方式是，Firefox 应该输出到 GTK+，GTK+ 应该输出到 DirectFB，DirectFB 应该输出到硬件。如果我错了，请纠正我。
As far as I understand, DirectFB offers hardware acceleration for many kinds of graphics cards. Additionally, it's smaller, faster, and uses up less memory than X11. Why then, is it not more mainstream than it is now?
Here's what I'm really unsure about: Do common GTK+/Qt programs need to be ported to it? On the DirectFB site, there's a project for porting Firefox to it. Why is that even necessary, if GTK+ has the ability to use DirectFB directly? The way I (probably incorrectly) understand it, is that Firefox should output to GTK+, which should output to DirectFB, which should output to the hardware. Please correct me if I'm wrong about that.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
如果您强调 X 作为现代 Linux 系统上的开销来源，那么您可能没有找对地方。 X 是很久以前为计算机设计的，其功能远不如现代手机强大。
如果您查看“top”并看到 X 使用内存，则需要做很多工作才能计算出实际的 X 开销。有些内存映射不是“真正的”内存，并且有些资源（例如大像素块）代表应用程序分配。最重要的是，顶部显示的 X 内存并不是人们想象的那样。
人们还听说 X 使用“网络”，并认为这将成为性能瓶颈。这里的“网络”指的是本地 UNIX 域套接字，它在现代 Linux 上的开销可以忽略不计。网络上会出现瓶颈的事情，有 X 扩展可以加快速度（共享内存像素图、DRI 等）。进程内线程不一定比 X 套接字更快，因为瓶颈更多地与协调访问同一硬件的多个线程或进程的固有问题有关，而不是与本地套接字的最小开销有关。
多进程设置有很多优点，例如更难崩溃。以 Google Chrome 为例，使用多个进程变得更加健壮 - 事实证明，也可以运行得更快。更少的流程并不一定意味着更现代。
使用 GTK 的应用程序无法透明地移植到 DirectFB 的原因有很多。对于 Firefox 来说，其一是有时它会直接使用 X。此外，一些独立于工具包的东西（例如浏览器插件接口）直接使用 X。例如，Flash 插件无法在 DirectFB 上运行。即使不直接使用 X 的应用程序通常也会假设存在正常的基于 X 的桌面环境（GNOME 等）。
替换 X 的另一个问题是驱动程序支持，两种更好的显卡（NVidia、ATI）都有比免费驱动程序功能更强的专有驱动程序，并且这些专有驱动程序与 X 绑定。
当然还有迁移小路。如果您有数百个应用程序使用 X 并且 X 没有明显的最终用户缺点，那么没有人会切换到没有应用程序工作的东西。最有可能的是，这里的解决方案是在新窗口系统上运行无根 X 服务器，因此旧应用程序仍然可以运行。
老并不总是坏事。 X 是由聪明人精心设计的，这使得它能够不断发展和变化，并且在多年后仍然有效。
无论如何，总而言之，基本上从 X 切换过来需要付出大量的努力，它确实工作得很好，而且“工作得很好”从来没有适用于任何替代方案（至少如果你希望能够在上面运行大多数应用程序的话）大多数硬件）。
X 存在一些问题 - 例如无法进行原子屏幕更新，这是 Wayland 项目正在研究的问题 - 但大多数问题对于用户来说确实是装饰性的（例如非原子更新）或对于开发人员来说是装饰性的（旧的已弃用的扩展）等）。放弃 X 并神奇地拥有更小、更快的东西是不真实的。这主要是基于人们推测“旧”和“使用网络”一定是缓慢且臃肿的，但同样，X 是为非常糟糕的硬件设计的。我曾经在我的 386 上运行 X（和 Emacs！），大概有 8 兆 RAM 或类似的东西。
If you're stressing about X as a source of overhead on a modern Linux system you probably aren't looking in the right place. X was designed a really long time ago for computers much less powerful than a modern cell phone.
If you look at "top" and see X using memory, there's a lot of work to do to figure out the actual X overhead. There are memory maps that aren't "real" memory, and there are resources (such as big blocks of pixels) allocated on behalf of apps. Bottom line the memory shown for X in top isn't what one might think.
People also hear that X uses the "network" and think this is going to be a performance bottleneck. "Network" here means local UNIX domain socket, which has negligible overhead on modern Linux. Things that would bottleneck on the network, there are X extensions to make fast (shared memory pixmaps, DRI, etc.). Threads in-process wouldn't necessarily be faster than the X socket, because the bottlenecks have more to do with the inherent problem of coordinating multiple threads or processes accessing the same hardware, than with the minimal overhead of local sockets.
The multi-process setup has a lot of advantages, such as being much harder to crash. See Google Chrome for example, using multiple processes to be more robust - and it turns out, also to run fast. Less processes does not necessarily mean more modern.
There are many reasons apps using GTK don't transparently port to DirectFB. For Firefox, one is that it uses X directly sometimes. Also, some toolkit-independent stuff such as the browser plugin interface uses X directly. Flash plugin would not work on DirectFB for example. Even apps that don't use X directly would often assume the normal X-based desktop environment exists (GNOME, etc.).
Another issue with replacing X is driver support, where both of the better graphics cards (NVidia, ATI) have proprietary drivers that are a good bit more capable than the free drivers, and those proprietary drivers are tied to X.
And of course there's migration path. If you have hundreds of apps using X and no clear end-user downside to X, nobody is going to switch to something where no apps work. Most likely, the solution here would be a rootless X server running on a new window system, so old apps still work.
Old is not always bad. X was very well-designed by smart people, and that has allowed it to evolve and change and still work many years later.
Anyway all a long way of saying, basically switching away from X is tons of effort, it really works fine, and "works fine" has never applied to any of the alternatives (at least if you want to be able to run most apps on most hardware).
There are issues with X - such as the impossibility of doing an atomic screen update, something the Wayland project is looking at - but most of the issues are really cosmetic for users (e.g. non-atomic updates) or cosmetic for developers (old deprecated extensions and the like). It just isn't true that one could drop X and magically have something much smaller and faster. That's mostly based on people speculating that "old" and "uses network" must be slow and bloated, but again, X was designed for really really crappy hardware. I used to run X (and Emacs!) fine on my 386 with maybe 8 megs of RAM or something like that.
x11 不仅仅是一种在屏幕上绘图的方式 - 它是一个完整的支持网络的桌面协议套件。 DirectFB 并不打算取代 x11（据我所知），而是与其并行运行。也就是说，DirectFB 致力于成为需要访问基本输入和图形输出的应用程序的轻量级“主机”。 X 服务器（X 中的服务器是显示内容的东西:-）可能是为了使用 DirectFB 而编写的。
DirectFB 上的 GTK 是与 X11 上的 GTK 不同
x11 is much more than just a way to draw to a screen - it's an entire network-capable desktop protocol suite. DirectFB does not intend to replace x11 (as far as I know) but rather runs parallel to it. That is, DirectFB strives to be a lightweight "host" for applications needing access to basic input and graphic output. It is possible that an X server (the server in X is the thing that displays things :-) is written to use DirectFB.
GTK on DirectFB is different than GTK on X11
很简单，因为 DirectFB 不能解决任何问题。对于嵌入式系统来说这很好，但对于桌面系统来说，你会损失很多，而且不会真正获得任何东西。
Simple, because DirectFB doesn't solve any problem. For embedded systems it's fine, but for desktop, you lose a lot and don't gain really anything.
DirectFB 专为内存占用较小的嵌入式系统而设计。它允许应用程序通过直接 API 直接与视频硬件对话，从而加速并简化图形操作。
游戏和嵌入式系统开发人员经常使用它来规避完整 X Window 系统服务器实现的开销。
http://elinux.org/DirectFB
DirectFB was designed for embedded systems, which have small memory footprint. It allows applications to talk directly to video hardware through a direct API, speeding up and simplifying graphic operations.
It is often used by games and embedded systems developers to circumvent the overhead of a full X Window System server implementation.
http://elinux.org/DirectFB
X11 比 DirectFB 更便携。 X11 应用程序可以在 Linux、BSD、Solaris、AIX、HP-UX、MacOS X、Windows（通过 Cygwin 或 Exceed）以及更多平台上运行。 DirectFB 几乎只适用于 Linux。
X11 is far more portable than DirectFB. An X11 app can run on Linux, BSD, Solaris, AIX, HP-UX, MacOS X, Windows (via Cygwin or Exceed), and many more platforms. DirectFB is pretty much Linux-only.
使用 XDirectFB 有一个使用 DirectFB 的无根 X 服务器。
With XDirectFB there is a rootless X Server using DirectFB.