Почему DirectFB более широко не используется в GNU/Linux? Там наносят вред ограничениям к нему, которые не существуют в X11?
Насколько я понимаю, DirectFB предлагает аппаратное ускорение для многих видов видеокарт. Кроме того, это меньше, быстрее, и израсходовало меньше памяти, чем X11. Почему затем, разве это не является более основным, чем это теперь?
Вот то, в чем я действительно не уверен: общий GTK +/Qt программы должен быть портирован к нему? На сайте DirectFB существует проект для портирования Firefox к нему. Почему это даже необходимо, если GTK + имеет способность использовать DirectFB непосредственно? Путь I (вероятно, неправильно) понимает это, то, что Firefox должен произвести к GTK +, который должен произвести к DirectFB, который должен произвести к аппаратным средствам. Исправьте меня, если я неправ относительно этого.
Спасибо,
Hassan
5 ответов
Если вас напрягает X как источник накладных расходов в современной системе Linux, то вы, вероятно, не там ищете. X был разработан очень давно для компьютеров гораздо менее мощных, чем современный сотовый телефон.
Если вы смотрите на "top" и видите, что X использует память, вам предстоит проделать большую работу, чтобы выяснить реальные накладные расходы X. Есть карты памяти, которые не являются "реальной" памятью, и есть ресурсы (например, большие блоки пикселей), выделяемые от имени приложений. В итоге память, показанная сверху для X, - это не то, что можно подумать.
Люди также слышат, что X использует "сеть", и думают, что это будет узким местом в производительности. "Сеть" здесь означает локальный сокет домена UNIX, который имеет незначительные накладные расходы в современном Linux. Для вещей, которые могут стать узким местом в сети, существуют расширения X, позволяющие сделать их быстрыми (пиксмапы общей памяти, DRI и т.д.). Потоки в процессе не обязательно будут быстрее, чем X-сокет, потому что узкие места связаны с проблемой координации нескольких потоков или процессов, обращающихся к одному и тому же оборудованию, а не с минимальными накладными расходами локальных сокетов.
Многопроцессная установка имеет много преимуществ, например, ее гораздо труднее повредить. Например, Google Chrome использует несколько процессов, чтобы быть более надежным - и, как оказалось, также быстро работать. Меньше процессов не обязательно означает больше современных.
Есть много причин, по которым приложения, использующие GTK, не переносятся прозрачно на DirectFB. Для Firefox одной из них является то, что он иногда использует X напрямую. Кроме того, некоторые независимые от инструментария вещи, такие как интерфейс плагинов браузера, используют X напрямую. Например, плагин Flash не будет работать на DirectFB. Даже приложения, которые не используют X напрямую, часто предполагают наличие обычной среды рабочего стола на базе X (GNOME и т.д.).
Другая проблема с заменой X - поддержка драйверов, где обе лучшие графические карты (NVidia, ATI) имеют проприетарные драйверы, которые имеют гораздо больше возможностей, чем свободные драйверы, и эти проприетарные драйверы привязаны к X.
И, конечно, есть путь миграции. Если у вас есть сотни приложений, использующих X, и нет явных недостатков X для конечного пользователя, никто не собирается переходить на что-то, где ни одно приложение не работает. Скорее всего, решением здесь будет сервер X без корней, работающий на новой оконной системе, так что старые приложения все еще работают.
Старое не всегда плохо. X был очень хорошо спроектирован умными людьми, и это позволило ему развиваться и меняться и все еще работать много лет спустя.
В общем, все это длинный способ сказать, что в основном переход от X - это тонна усилий, он действительно работает хорошо, и "работает хорошо" никогда не относилось ни к одной из альтернатив (по крайней мере, если вы хотите иметь возможность запускать большинство приложений на большинстве аппаратных средств).
В X есть проблемы - например, невозможность атомарного обновления экрана, над чем сейчас работает проект Wayland - но большинство из них носят косметический характер для пользователей (например, неатомарные обновления) или косметический характер для разработчиков (старые устаревшие расширения и тому подобное). Это просто неправда, что можно отказаться от X и волшебным образом получить что-то гораздо меньшее и более быстрое. Это в основном основано на предположениях людей, что "старое" и "использующее сеть" должно быть медленным и раздутым, но опять же, X был разработан для действительно очень дрянного оборудования. Я прекрасно запускал X (и Emacs!) на своем 386-м с 8 мегабайтами оперативной памяти или чем-то подобным.
x11 - это гораздо больше, чем просто способ рисования на экране - это целый набор протоколов для настольных компьютеров с поддержкой сети. DirectFB не собирается заменять 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.