blocks|key|976891|text|很简单，因为DirectFB不能解决任何问题。对于嵌入式系统来说，这很好，但是对于台式机来说，你会失去很多东西，但并没有真正获得任何东西。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|976892|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

blocks|key|976921|text|x11不仅仅是一种绘制到屏幕上的方式--它是一个完整的支持网络的桌面协议套件。DirectFB并不打算取代x11+(据我所知)，而是与之并行运行。也就是说，DirectFB努力成为需要访问基本输入和图形输出的应用程序的轻量级“主机”。可以将X服务器(X中的服务器是显示内容的部分:-)编写为使用DirectFB。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|976922|GTK+on+DirectFB+is+different+than+GTK+on+X11|976923|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/DirectFB|1|https://web.archive.org/web/20150103061504/http://www.directfb.org/wiki/index.php/Projects:GTK_on_DirectFB^0|13|8|0|0|0|18|1|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@$A|U|B|V|1|W]]|C|$]]|$1|F|3|-4|5|6|7|X|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]|N|$5|I|J|K|C|$L|O]]]]

x11 is much more than just a way to draw to a screen - it's an entire network-capable desktop protocol suite. <a href="http://en.wikipedia.org/wiki/DirectFB" rel="nofollow noreferrer">DirectFB</a> 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 &quot;host&quot; 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.
<a href="https://web.archive.org/web/20150103061504/http://www.directfb.org/wiki/index.php/Projects:GTK_on_DirectFB" rel="nofollow noreferrer">GTK on DirectFB is different than GTK on X11</a>

blocks|key|1191198|text|DirectFB是为内存占用较小的嵌入式系统设计的。它允许应用程序通过直接API直接与视频硬件对话，从而加快并简化图形操作。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1191199|游戏和嵌入式系统开发人员经常使用它来规避完整的X+Window+System服务器实现的开销。|1191200|http://elinux.org/DirectFB|1191201|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/DirectFB|1^0|0|8|0|0|0|0|Q|1|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@$A|R|B|S|1|T]]|C|$]]|$1|D|3|E|5|6|7|U|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|V|8|@]|9|@$A|W|B|X|1|Y]]|C|$]]|$1|H|3|-4|5|6|7|Z|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]|P|$5|K|L|M|C|$N|G]]]]

<a href="http://en.wikipedia.org/wiki/DirectFB" rel="noreferrer">DirectFB</a> 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.

<a href="http://elinux.org/DirectFB" rel="noreferrer">http://elinux.org/DirectFB</a>

blocks|key|1191252|text|与DirectFB相比，X11的可移植性要强得多。X11应用程序可以在Linux、BSD、Solaris、AIX、HP-UX、Windows、Windows(通过Cygwin或Exceed)以及更多平台上运行。DirectFB在很大程度上是基于Linux的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1191253|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

blocks|key|1191298|text|如果您担心X是现代Linux系统的开销来源，那么您可能找错了地方。X是很久以前为比现代手机功能差得多的电脑设计的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1191299|如果您查看"top“并看到X正在使用内存，那么要计算出实际的X开销还有很多工作要做。有不是“真实”内存的内存映射，还有代表应用程序分配的资源(例如大块像素)。归根结底，顶部显示的X的内存并不是人们可能认为的那样。|1191300|人们还听说X使用“网络”，并认为这将是一个性能瓶颈。这里的“网络”指的是本地UNIX域套接字，它在现代Linux上的开销可以忽略不计。对于那些会成为网络瓶颈的东西，有X个扩展可以让它变得更快(共享内存像素图、DRI等)。进程内线程不一定比X套接字快，因为瓶颈更多地与协调访问相同硬件的多个线程或进程的固有问题有关，而不是与本地套接字的最小开销有关。|1191301|多进程设置有很多优点，比如更难崩溃。以Google+Chrome为例，它使用多个进程来增强健壮性--事实证明，它也可以运行得更快。更少的流程并不一定意味着更现代化。|1191302|使用GTK的应用程序不能透明地移植到DirectFB有很多原因。对于Firefox来说，其一是它有时会直接使用X。此外，一些与工具包无关的东西，如浏览器插件界面，直接使用X。例如，Flash插件不能在DirectFB上工作。即使不直接使用X的应用程序通常也会假设存在正常的基于X的桌面环境(GNOME等)。|1191303|替换X的另一个问题是驱动程序支持，两种较好的显卡(NVidia、ATI)都有专有驱动程序，这些驱动程序比免费驱动程序更强大，而且这些专有驱动程序与X捆绑在一起。|1191304|当然还有迁移路径。如果你有成百上千的应用程序在使用X，而没有明确的终端用户对X的负面影响，那么没有人会切换到没有应用程序工作的东西。最有可能的是，这里的解决方案是在一个新的窗口系统上运行一个无根的X服务器，这样旧的应用程序仍然可以工作。|1191305|老并不总是坏事。X是由聪明人精心设计的，这使得它能够进化和变化，并在许多年后仍然有效。|1191306|无论如何，长话短说，基本上从X切换是大量的努力，它真的工作得很好，“工作得很好”从来没有适用于任何替代方案(至少如果你想要能够在大多数硬件上运行大多数应用程序)。|1191307|X存在一些问题--比如不可能进行原子屏幕更新，这是Wayland项目正在关注的问题--但大多数问题对用户来说都是表面化的(例如非原子更新)，或者对开发人员来说是表面化的(旧的、不推荐使用的扩展等等)。这是不正确的，一个人可以放弃X，并神奇地拥有更小，更快的东西。这主要是基于人们猜测“旧的”和“使用网络”肯定是缓慢和臃肿的，但同样，X是为非常糟糕的硬件而设计的。我曾经运行过X(还有Emacs!)在我的386内存大概是8兆内存或者类似的东西上运行很好。|1191308|entityMap^0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|X|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Y|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|Z|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|10|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|11|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|12|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|13|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|14|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|U|$]]

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.

blocks|key|977092|text|在XDirectFB中，有一个使用DirectFB的无根X服务器。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|977093|entityMap|0|LINK|mutability|MUTABLE|url|https://web.archive.org/web/20150324105419/http://www.directfb.org/index.php?path=Projects%252FXDirectFB^0|1|9|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

With <a href="https://web.archive.org/web/20150324105419/http://www.directfb.org/index.php?path=Projects%2FXDirectFB" rel="nofollow noreferrer">XDirectFB</a> there is a rootless X Server using 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.

Why is DirectFB not more widely used in GNU/Linux? Are there crippling limitations to it that don't exist in X11?

嵌入式系统

内存映射

服务器

Windows

Solaris

Wayland 

Linux

GNOME

据我所知，DirectFB为许多类型的显卡提供硬件加速。此外，它比X11更小、更快，并且占用的内存更少。那么，为什么它不比现在更主流呢？这是我真正不确定的:普通的GTK+/Qt程序需要移植到它上吗？在DirectFB站点上，有一个将Firefox移植到该站点的项目。如果GTK+有能力直接使用DirectFB，那么为什么...

问为什么DirectFB没有在GNU/Linux中得到更广泛的应用？它有没有X11中不存在的严重限制？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么DirectFB没有在GNU/Linux中得到更广泛的应用？它有没有X11中不存在的严重限制？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么DirectFB没有在GNU/Linux中得到更广泛的应用？它有没有X11中不存在的严重限制？
EN