> 1) Кульный протоколец иксов - тормоз и жрет ресурсы, так что графическая
> подсистема не соответствует ожиданиям большинства пользователей. Извините, но главный тормоз - это XRender. Если пользоваться изначальными примитивами Х, в которых нет alpha-канала (его надо было по-человечески добавить в 1996-м году), не тормозит ничего.
> 2) Ну да, на третий день Зоркий Глаз заметил что у DRI2
> оказывается были недостатки и можно сделать даже еще лучше. Особенно после
> того как DMA-BUF сделали.
Ну вот пока Зоркий Глаз будет думать ИСКЛЮЧИТЕЛЬНО в терминах - как ускорить вывод графики ещё 1.5 раза, дела не будет. Ибо основная задача Х - это не вывод 4К видео, а построение скелета графического интерфейса пользователя. А 4К видео - это важная, безусловно, часть, но несколько второстепенная.
И, заметьте, прогресс железа может костыльным образом исправить тормознутость Х, но вот отсутствие минимизации/максимизации в Wayland никакими мега видеокартами и ЦП не исправить.
>[оверквотинг удален]
> Это стандартное состоение дел в больших проектах. Это нормально. Например, очень врядли
> что вы сможете вгрузить в ваш мозг архитектуру обычного писюка целиком
> и полностью. На уровне разработчика. Просто потому что это такой навороченный
> комплекс, что это примерно то же самое как требовать от архитектора
> вгрузить себе в мозг план всего города с миллионами жителей, с
> точностью до планировки квартир в каждом доме. Это нереально. Поэтому архитектор
> будет работать с своим закоулком.
>> ещё масса других вещей, неизменных со времён царя Гороха - не осознают.
> Это опять же нормально. Сначала надо решать базовые инфраструктурные задачи. А уже
> потом поверх нормально работающей структуры можно навороты строить.
Нет, это не нормально. Большие системы в таких случаях бьют на малые системы, проводят анализ на языке этих малых систем, не вдаваясь в подробности - на это человеческого мозга хватает. Но обязательно наряду с рассматриванием закоулков нужно иметь хороший взгляд с птичьего полёта.
А поверх строить нельзя - W пилится уже 5 лет, а до сих пор на нём нормально KDE не взгромоздить. Пусть даже тормознуто.
> Просто современные видеокарты отличаются от SVGA адаптера настолько же, насколько боинг
> отличается от этажерки братьев Райт.
А пользовательские задачи не отличаются практически никак - те же мышь, условное световое перо, клавиатура, несколько экранов, несколько машин под управлением одного пользователя. Это условия Х, соответственно, для построения инфраструктуры, заменяющей Х нужна система, учитывающая всё это. Но не очередная SVGAlib.
>> "закона Мура" обречённая на гибель лет через 5, когда производительность железа
>> подрастёт до нужного уровня.
> Где-то я это уже слышал.
Даже могли видеть, наблюдая за SVGAlib и DirectFB - в своё время они здорово помогали выводить видео с нужной скоростью. Но мощности подросли и Х стали тянуть и видео.
> При том по мере роста закона Мура
> растут и запросы пользователей насчет качества графики, разрешений экранов и прочая.
Разрешения экранов не растут - я тут с трудом добыл себе QXGA, 8-ми летней давности. Сейчас такие не выпускаются.
> И в случае разрешения экрана зависимость аж квадратичная. Спокойно заткнет любой
> закон Мура за пояс.
Закон Мура экспоненциальный, друг мой. Собственно, всё у вас так - гонетесь за 2-х кратным ускорением в одном узком месте, убирая реально нужнейшие вещи.
> И вот чего-чего, а производительность оперативной памяти
> растет медленно. А при таких разрешениях экрана там летают натурально гигабайты
> данных.
И что? Раньше летали мегабайты и это тоже поражало. Не переживайте, мощность растёт.
> И парочка лишних копирований и парсинг протокола может быть весьма
> серьезным факапом.
Ну не смешите, парочка лишних копирований - это всего лишь 2 раза. Задача высокопараллельная, поэтому достаточно вставить 2 видяхи и всё, дело сделано.
> Ну понятно что в математических программах этого обычно нет.
В математических программах, ради 2-х раз никто не руки не марает. Только особо упоротые, т.к. смена алгоритма приводит к ускорению минимум на порядок, а то и несколько. Вам не хватает 4-х Гб памяти или 2-х ядер процессора? Поверьте, докупить ещё столько же много дешевле, чем править код.
> И то - достаточно возжелать выплюнуть реалтаймную картинку осциллограммы сигнала на
> экран - и вот вам уже немеряные потоки данных на экран.
И? Смысл оптимизировать вручную есть тогда, когда либо это highload и стоимость всех серваков, где гоняется программа, запредельна, либо когда выигрыш - порядок, а не жалкие 2 раза.
> Вроде бы было так логично - читаешь отсчеты со входа - рисуешь график на экран.
> А тут тебе и говорят: хрен тебе, золотая рыбка. Изволь сперва изогнуться буквой зю и
> задетектить пяток опциональных расширений. А если их нету - придумай что
> будешь делать в этом случае.
У вас не 2 раза провал по производительности, а больше. Ну возьмите DirectFB и SVGAlib, сделайте свою частную программу под них и не используйте Х там, где она не пашет. Кстати, в осциллографе linux вообще использовать не стоит, т.к. не ОС реального времени. А уж Х - тем более.
