Почему DirectFB не используется более широко в GNU/Linux? Существуют ли калечащие ограничения для этого, которых нет в X11?

Насколько я понимаю, DirectFB предлагает аппаратное ускорение для многих видов видеокарт. Кроме того, он меньше, быстрее и использует меньше памяти, чем X11. Почему же тогда это не больше, чем сейчас?

Вот о чем я действительно не уверен: нужны ли для этого общие программы GTK +/Qt? На сайте DirectFB есть проект по переносу Firefox на него. Почему это необходимо, если GTK + имеет возможность напрямую использовать DirectFB? То, как я (возможно, неправильно) понимаю это, заключается в том, что Firefox должен выводить на GTK +, который должен выводиться в DirectFB, который должен выводиться на аппаратное обеспечение. Пожалуйста, поправьте меня, если я ошибаюсь.

Спасибо,

Хассан

Ответ 1

Если вы подчеркиваете, что X является источником накладных расходов на современной Linux-системе, вы, вероятно, не смотрите в нужное место. X был разработан очень давно, для компьютеров, гораздо менее мощных, чем современный сотовый телефон.

Если вы посмотрите "сверху" и посмотрите на Х, используя память, там будет много работы, чтобы выяснить фактические накладные расходы X. Существуют карты памяти, которые не являются "реальной" памятью, и есть ресурсы (такие как большие блоки пикселей), выделенные от имени приложений. В нижней строке память, показанная для вершины X, не является тем, о чем можно подумать.

Люди также слышат, что X использует "сеть" и думает, что это будет узким местом производительности. "Сеть" здесь означает локальный сокет домена UNIX, который имеет незначительные накладные расходы в современной Linux. Вещи, которые были бы узким местом в сети, есть X-расширения для быстрого создания (pixmaps разделяемой памяти, DRI и т.д.). Threads in-process не обязательно будет быстрее, чем X-сокет, потому что узкие места больше связаны с присущей проблемой координации нескольких потоков или процессов, обращающихся к одному и тому же оборудованию, чем с минимальными издержками локальных сокетов.

У многопроцессорной установки есть много преимуществ, таких как гораздо сложнее сбой. Например, см. Google Chrome, используя несколько процессов, чтобы быть более надежными - и, оказывается, также быстро запускать. Меньше процессов не обязательно означает более современный.

Существует множество причин, по которым приложения, использующие GTK, не прозрачно портят в DirectFB. Для Firefox один из них заключается в том, что он иногда использует X. Кроме того, некоторые инструменты, не зависящие от инструментария, такие как интерфейс плагина браузера, напрямую используют X. Например, плагин Flash не работает с DirectFB. Даже приложения, которые не используют X напрямую, часто предполагают, что обычная среда рабочего стола на основе X существует (GNOME и т.д.).

Еще одна проблема с заменой X - поддержка драйверов, в которой обе лучшие видеокарты (NVidia, ATI) имеют проприетарные драйверы, которые являются более гибкими, чем свободные драйверы, и эти проприетарные драйверы привязаны к X.

И, конечно, путь миграции. Если у вас сотни приложений, использующих X, и отсутствие явного недостатка конечного пользователя для X, никто не собирается переключаться на что-то, где приложения не работают. Скорее всего, решение здесь было бы сервером без корней, работающим в новой оконной системе, поэтому старые приложения все еще работают.

Старый не всегда плохой. X был очень хорошо разработан умными людьми, и это позволило ему развиваться и меняться и все еще работать много лет спустя.

В любом случае, весь длинный способ сказать, в основном, отключение от X - это тонна усилий, он действительно работает отлично, и "отлично работает" никогда не применялся ни к одной из альтернатив (по крайней мере, если вы хотите иметь возможность запускать большинство приложений на большинстве аппаратных средств).

Есть проблемы с X - такие, как невозможность сделать обновление на атомарном экране, что-то, на что смотрит проект Wayland, - но большинство проблем действительно косметические для пользователей (например, неатомные обновления) или косметические для разработчиков ( старые устаревшие расширения и т.п.). Просто неправда, что можно было бы сбросить X и магически иметь что-то намного меньшее и быстрое. Это в основном основано на людях, предполагающих, что "старая" и "использующая сеть" должна быть медленной и раздутой, но опять же X был разработан для действительно действительно дерьмового оборудования. Раньше я использовал X (и Emacs!) На моем 386, возможно, 8 мегабайт ОЗУ или что-то в этом роде.

Ответ 2

x11 - это гораздо больше, чем просто способ рисовать на экране - это целый набор протоколов настольных протоколов, совместимых с сетью. DirectFB не намеревается заменить x11 (насколько я знаю), а скорее работает параллельно с ним. То есть DirectFB стремится быть легким "хостом" для приложений, которым необходим доступ к основному входному и графическому выходному сигналу. Возможно, что X-сервер (сервер в X - это вещь, которая отображает вещи:-) написана для использования DirectFB.

GTK на DirectFB отличается от GTK на X11.

Ответ 3

Просто, потому что DirectFB не решает никаких проблем. Для встраиваемых систем это прекрасно, но для рабочего стола вы теряете много и ничего не получаете.

Ответ 4

DirectFB был разработан для встроенных систем, которые имеют небольшой объем памяти. Он позволяет приложениям напрямую общаться с видеооборудованием через прямой API, ускоряя и упрощая графические операции.

Он часто используется разработчиками игр и встроенных систем, чтобы обойти накладные расходы на полную реализацию сервера X Window System.

http://elinux.org/DirectFB

Ответ 5

X11 гораздо более портативен, чем DirectFB. Приложение X11 может работать на Linux, BSD, Solaris, AIX, HP-UX, MacOS X, Windows (через Cygwin или Exceed) и на многих других платформах. DirectFB в значительной степени Linux-only.

Ответ 6

С XDirectFB существует сервер без корневого сервера, использующий DirectFB.