Comments 30
который работает в два раза быстрее по производительности рендеринга на базе GPU, чем текущие проекты
Друзья, объясните мне, что вообще такого нужно сделать с терминалом, чтобы у него в принципе возникли проблемы с производительностью? Это же простейшая плоская картинка с текстом. Даже если хочется странненького, например, подложить ему полноцветную фоновую картинку, с ним прекрасно будут справляться компьютеры даже четвертьвековой давности, и без какого-либо GPU-рендеринга.
Кстати интересный вопрос. Хотелось бы чтоб кто нибудь ответил по существу :)
Судя по тексту от автора – "because we can". Просто упражнение по оптимизации отрисовки на примере терминала.
А никто и не говорил что есть проблема с производительностью. Но это не значит, что нельзя её повысить, хотя может это и нафиг не нужно.
Cool retro term достаточно сильно нагружал систему за счёт эффектов.
Насколько медленно работает терминал можно легко увидеть, допустим если запустить приложение, которое выводит в реальном времени в stdout плотный поток логов (как вариант - любое через strace). Тогда даже невооружённым глазом заметно, насколько приложение начинает тормозить из-за задержек на стороне терминала.
В плане сложностей с графикой современный терминал не сильно уступает тому же браузеру. Четверть века тому назад ни кто не мечтал о 32bit цветах, разрешениях 4К, векторных шрифтах с кернингом и антиалиасингом. Плавность и скорость прокрутки и возможность перерисовки с частотой 60 кадров в секунду тоже мало кого волновала.
А смысл выводить логи с такой скоростью, чтобы появились лаги? Чтобы снять кино про хакеров? Все равно что-то больше одного экрана уже лучше выводить в файл
Фигасе реакция... а теперь поднимите руку те, кто сможет осмысленно читать и понять вывод в терминал со скоростью 60 кадров в секунду
Самый типичный (но тоже редкий) случай – по ошибке не поставил редирект, и теперь прога тормозит.
Я отвечал лишь на вопрос про перфоманс, и зачем тут понадобился GPU. На практике всё зависит от набора ваших приложений, сценариев использования и зоны комфорта. У кого-то компилятор выводит отладку, кто-то листает man, кто-то может до сих пор пользуется emacs, lynx и mutt.
Логи могут быть не нужны вообще. Но сначала всё затормозит, потом грохнешь окно, а потом уже запустишь с перенаправлением.
И есть другой пример - если вставить большой объем данных в клиент mysql, то не просто тормозит, но и теряется часть текста. Не уверен, что связано с терминалом, но очень похоже.
Четверть века тому назад ни кто не мечтал о 32bit цветах, разрешениях 4К, векторных шрифтах с кернингом и антиалиасингом.
Четверть века назад, это 1998-й год. Тогда не было разрешений 4К, но шрифты уже были векторные с антиалиасингом, цвет массово 16-битный, а на новых машинах 32-битный. Ну т.е. ничего такого, существенно отличавшегося от современности. Пусть "физически" сложность отрисовки окна терминала выросла в несколько раз, ну так и производительность компьютеров выросла... в несколько тысяч раз.
Не, ну люди как-то справляются.. Вон, в вин10 отключали мигание курсора, так как жрало просто дофига ресурсов на перерисовку. Аналогично пропало мигание у двоеточия в часах в трее. Так что терминал с кучей сложного кода сломать вообще не проблема)
В Windows исторически свои сложности. Там терминал с консолью это несколько компонентов и сервисов, размазанных по разным слоям и изоляциям. Основной упор они делали на безопасности и так чтобы не ломать совместимость с разным легаси ещё со времён DOS. Но конечная перерисовка даётся дорого.
В GNOME точно так же ограничено число миганий курсора для экономии энергии.
Просто надо выполнить несколько команд в терминале и посмотреть, что из этого выйдет. Шутка!
https://wiki.gnome.org/Apps/Builder/Downloads
$ flatpak install --from https://flathub.org/repo/appstream/org.gnome.Builder.flatpakref
$ flatpak run org.gnome.Builder//stable
Знаю как минимум одного человека который работает в виме и сильно ругается на скорость вывода в современных терминалах - дескать буквы после ввода с задержкой появляются во всех этих модных терминалах - и как-то пытается с этим бороться.
Ну т.е. речь скорее про лаг чем про производительность в целом.
А в каких конкретно модных терминалах? Пользуюсь модным прозрачным guake на питоне, задержек, вызванных терминалом, не замечено, только из-за сети или если мегабайты текста вставлять, но последнее - фишка вима, с заботой переносимая из версии в версию.
Это надо у человека спрашивать. Как минимум ругался на стандартный терминал мак оси, дальше я не копал. Я сам в то время пользовался преимущественно хромбуком с vs code сервером на удаленной рабочей станции и рендером в браузер и не испытывал больших проблем с этим, поэтому будем меня считать очень толерантным к задержкам ввода.
Сейчас есть Терминалы на Электроне...
А условный https://termius.com/ далеко не просто "простейшая плоска картинка с текстом".
Условный термиус - это простейшая плоская картинка с текстом, и ещё нехитрыми формами/вкладками (которые были по зубам 386-м компьютерам с Windows 3.11), но на Электроне. Да, по поводу Электрона - понятно. Но тут и ответ достаточно простой: чтобы не было проблем с производительностью, достаточно просто не писать на Электроне.
Здесь много нюансов, в основном связанных с нестандартными шрифтами/кодировками и управляющими командами. Вот пример - https://github.com/microsoft/terminal/issues/10362 - это была драма в нескольких действиях в своё время :)
Да много чего можно, если есть богатая фантазия: https://youtu.be/AXnLjMpkRp8?t=54
Разработчик Gnome Builder создал новый эмулятор терминала, который в два раза быстрее, чем Alacritty