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

我的梦境 提交于 2019-12-09 04:35:30

问题


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


回答1:


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.




回答2:


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.




回答3:


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.




回答4:


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




回答5:


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.




回答6:


With XDirectFB there is a rootless X Server using DirectFB.



来源:https://stackoverflow.com/questions/3327767/why-is-directfb-not-more-widely-used-in-gnu-linux-are-there-crippling-limitatio

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!