私の知る限り、DirectFB は多くの種類のグラフィックス カードにハードウェア アクセラレーションを提供します。さらに、X11 よりも小さく、高速で、使用するメモリが少なくなります。では、なぜ今よりも主流にならないのでしょうか?
ここに私が本当に確信していないことがあります: 一般的な GTK+/Qt プログラムを移植する必要がありますか? DirectFB サイトには、Firefox を移植するためのプロジェクトがあります。GTK+ が DirectFB を直接使用できるのに、なぜそれが必要なのでしょうか? 私が（おそらく間違って）それを理解する方法は、Firefox が GTK+ に出力し、それが DirectFB に出力し、それがハードウェアに出力するということです。私がそれについて間違っている場合は、私を修正してください。
最新の Linux システムのオーバーヘッドの原因として X を強調している場合は、適切な場所を探していない可能性があります。X は、現代の携帯電話よりもはるかに性能の低いコンピュータ向けに、かなり昔に設計されました。
"top" を見て、X がメモリを使用していることがわかれば、実際の X オーバーヘッドを把握するためにやるべきことがたくさんあります。「実際の」メモリではないメモリ マップがあり、アプリに代わって割り当てられたリソース (ピクセルの大きなブロックなど) があります。要するに、上部の X に示されているメモリは、人が考えているものとは異なります。
また、X が「ネットワーク」を使用していると聞いて、これがパフォーマンスのボトルネックになると考えています。ここでの「ネットワーク」はローカルの UNIX ドメイン ソケットを意味し、最新の Linux ではオーバーヘッドはごくわずかです。ネットワーク上でボトルネックになるものは、高速化するための X 拡張機能 (共有メモリ ピックスマップ、DRI など) があります。ボトルネックは、ローカル ソケットの最小限のオーバーヘッドよりも、同じハードウェアにアクセスする複数のスレッドまたはプロセスを調整するという固有の問題に関係しているため、プロセス内のスレッドは必ずしも X ソケットよりも高速ではありません。
マルチプロセス設定には、クラッシュしにくいなど、多くの利点があります。たとえば、複数のプロセスを使用してより堅牢にする Google Chrome を参照してください。プロセスが少ないからといって、必ずしもより近代的であるとは限りません。
GTK を使用するアプリが透過的に DirectFB に移植されない理由は多数あります。Firefox の場合、X を直接使用することがあります。また、ブラウザ プラグイン インターフェイスなどの一部のツールキットに依存しないものは、X を直接使用します。たとえば、Flash プラグインは DirectFB では機能しません。X を直接使用しないアプリでさえ、通常の X ベースのデスクトップ環境 (GNOME など) が存在すると想定することがよくあります。
X の置き換えに関するもう 1 つの問題は、ドライバーのサポートです。より優れたグラフィックス カード (NVidia、ATI) の両方に、無料のドライバーよりもかなり優れた独自のドライバーがあり、これらの独自のドライバーは X に関連付けられています。
もちろん、移行パスもあります。X を使用するアプリが何百もあり、X の明確なエンドユーザーの欠点がない場合、アプリが機能しないものに切り替える人は誰もいません。おそらく、ここでの解決策は、新しいウィンドウ システムで実行されるルートレス X サーバーであるため、古いアプリは引き続き機能します。
古いことは必ずしも悪いことではありません。X は賢い人々によって非常によく設計されており、そのおかげで X は進化し、変化し、何年も経った今でも機能しています。
とにかく長い言い方をすれば、基本的に X から切り替えるのは大変な労力であり、実際に問題なく動作し、「問題なく動作する」というのはどの選択肢にも当てはまりませんでした (少なくとも、ほとんどのアプリを X で実行できるようにしたい場合)。ほとんどのハードウェア)。
X には問題があります - たとえば、Wayland プロジェクトが検討しているアトミック スクリーン アップデートを実行できないなどです - しかし、ほとんどの問題は、ユーザーにとっては表面的なもの (非アトミックなアップデートなど) または開発者にとっては表面的なもの (古い非推奨の拡張機能) です。など）。X を落として、魔法のようにはるかに小さくて速いものを手に入れることができるというのは真実ではありません。それは主に、「古い」および「ネットワークを使用する」は遅くて肥大化しているに違いないと推測する人々に基づいていますが、X は本当にひどいハードウェア用に設計されています。私は 386 で X (および Emacs!) を 8 メガバイトの RAM などで問題なく実行していました。
x11 は、単なる画面への描画方法ではなく、ネットワーク対応のデスクトップ プロトコル スイート全体です。DirectFBは (私が知る限り) x11 を置き換えるつもりはなく、x11 と並行して動作します。つまり、DirectFB は、基本的な入力とグラフィック出力へのアクセスを必要とするアプリケーションの軽量な「ホスト」になることを目指しています。Xサーバー（Xのサーバーは物事を表示するものです:-)がDirectFBを使用するように書かれている可能性があります。
DirectFB は問題を解決しないため、簡単です。組み込みシステムの場合は問題ありませんが、デスクトップの場合は多くを失い、実際には何も得られません。
DirectFBは、メモリ フットプリントが小さい組み込みシステム用に設計されました。これにより、アプリケーションはダイレクト API を介してビデオ ハードウェアと直接やり取りできるようになり、グラフィック操作が高速化および簡素化されます。
これは、ゲームや組み込みシステムの開発者が X Window System サーバーの完全な実装のオーバーヘッドを回避するためによく使用します。
X11 は、DirectFB よりも移植性がはるかに優れています。X11 アプリは、Linux、BSD、Solaris、AIX、HP-UX、MacOS X、Windows (Cygwin または Exceed 経由)、およびその他多くのプラットフォームで実行できます。DirectFB はほぼ Linux 専用です。
XDirectFBには、DirectFB を使用するルートレス X サーバーがあります。