为什么DirectFB在GNU / Linux中不被更广泛地使用？是否存在X11中不存在的限制？ [英] Why is DirectFB not more widely used in GNU/Linux? Are there crippling limitations to it that don't exist in X11?

问题描述

据我所知，DirectFB为多种显卡提供硬件加速。此外，它比X11更小，更快，占用的内存也更少。那么为什么它不是现在的主流呢？

下面是我真正不确定的：常用的GTK + / Qt程序需要移植到它上面吗？在DirectFB网站上，有一个将Firefox移植到它的项目。如果GTK +能够直接使用DirectFB，甚至有必要这么做？我（可能错误地）理解它的方式是，Firefox应该输出到GTK +，它应该输出到DirectFB，它应该输出到硬件。如果我错了，请纠正我。

谢谢，

Hassan

解决方案

如果你在现代Linux系统上强调X是开销的来源，那么你可能并没有找到正确的位置。 X很早以前就被设计用于比现代手机功能强大得多的计算机。

如果您查看top并查看使用内存的X，则有很多的工作要弄清楚实际的X开销。存储器映射不是真实的存储器，并且有代表应用程序分配的资源（如大块像素）。底线X显示的内存不是人们想象的内容。人们也听说X使用网络，并认为这将是一个性能瓶颈。这里的网络表示本地UNIX域套接字，它在现代Linux上的开销可以忽略不计。在网络上遇到瓶颈的事情，有X扩展快速（共享内存像素图，DRI等）。进程内的线程不一定比X套接字快，因为瓶颈更多的是协调多个线程或进程访问相同硬件的固有问题，而不是本地套接字的最小开销。

多进程设置有很多优点，比如更难以崩溃。例如，看看谷歌浏览器，使用多个进程更健壮 - 事实证明，也可以快速运行。更少的流程并不一定意味着更现代化。

使用GTK的应用程序没有透明地连接到DirectFB的原因很多。对于Firefox，有一点是它有时直接使用X.另外，一些与工具包无关的东西，比如浏览器插件接口，直接使用X.例如，Flash插件在DirectFB上不起作用。即使是不直接使用X的应用程序，也会经常假定存在普通的基于X的桌面环境（GNOME等）。

替换X的另一个问题是驱动程序支持，其中两个更好的显卡（NVidia，ATI）拥有比自由驱动程序更好的专有驱动程序，并且这些专有驱动程序与X绑定。

<当然还有迁移途径。如果您有数百个使用X的应用程序，并且X没有明确的最终用户缺点，则没有人会切换到没有应用程序的应用程序。最有可能的是，这里的解决方案将是一个运行在新窗口系统上的无根X服务器，所以旧的应用程序仍然有效。

旧并不总是坏。 X被聪明人设计得非常好，这让它发展变化，并在多年后仍然有效。

总之，基本上说，基本上切换离开X是很多努力，它确实工作正常，并且正常工作从未应用于任何替代方案（至少如果您希望能够在大多数硬件上运行大部分应用程序）。

$ b - b

X存在问题 - 比如不可能进行原子屏幕更新，Wayland项目正在研究 - 但大多数问题对于用户来说都非常美观（例如非原子更新）或开发者的化妆品（旧的弃用扩展等）。只能放弃X并且神奇地拥有更小更快的东西是不正确的。这主要是基于人们猜测旧和使用网络必须缓慢和臃肿，但是再一次，X被设计用于非常蹩脚的硬件。我曾经在我的386上运行X（和Emacs！），可能有8兆内存或类似的东西。

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.

Thanks,

Hassan

解决方案

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.

这篇关于为什么DirectFB在GNU / Linux中不被更广泛地使用？是否存在X11中不存在的限制？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！