Опубликован первый стабильный выпуск эмулятора терминала Ghostty, использующего GPU для ускорения отрисовки содержимого. Автор Ghostty пытается воплотить в одном приложении три качества - высокую производительность, обширную функциональность и интерфейс, выглядящий родным для каждой поддерживаемой платформы. Код проекта написан на языке Zig и распространяется под лицензией MIT. Готовые сборки сформированы для Linux и macOS...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=62471
> первый стабильный выпуск эмулятора
> zigТак zig сам по себе ещё нестабильный. И это косвенно влияет на стабильность ghostty.
Может кто пояснить зачем гпу для эмулятора терминала?
Чтобы интегрировать этот терминал в трёхмерные видеоигры про хакеров.
...но в бухгалтерии всё перепутали...
рисовать эмодзи
гиперссылки, сложные графемы и лигатуры
странно, я гиперссылки могу отобразить в простейшем ascii блокноте, и ВНИМАНИЕ(!) даже в командной строке.
странно, я гиперссылки могу отобразить в простейшем ascii блокноте, и ВНИМАНИЕ(!) даже в командной строке.
Затем же, зачем трёхмерные столы, тени, жидкие и сгорающие окна, ПОЛУПРОЗРАЧНОСТЬ и другие свистоперделки.
Ну, ПОЛУПРОЗРАЧНОСТЬ иногда даже очень уместно смотрится
Можно пример?
Когда бывает нужен полупрозрачный терминал и почему нельзя без оного?
Когда у тебя на рабочий стол установлен анимированный валпапер "Матрица", и он должен просматриваться сквозь полупрозрачный терминал.
Когда двигаешь окно терминала - оно становится полупрозрачным. Таким образом, иницировав движение по альт_правая кнопка мыши, даже не двигая окно (в том числе полноразмекрное) можно глянуть на приложение в фоне, не завершилось ли выполнение задачи.
Conky на рабочем столе рисует графики загрузки памяти, цпу, диска и т.д.
Можно смотреть на эти графики через полупрозрачную консоль. Если рама закончилась и что-то полезло в своп, то можно увидеть это, даже если оконный менеджер на некоторое время завис.
чтобы майнить
Меньше данных передаётся с CPU на GPU, а это основной затык производительности. Особенно если речь идёт о 4к мониках. Один фрейм полноэкранный это уже примерно 32 мегабайта на фрейм между прочим. Где-то 2-4 гигабайта в секунду в зависимости от фремрейта.
Данные с CPU на GPU особо и не передаются. Проблема в том, что отрисовать содержимое окна терминала на процессоре медленне чем на видяхе. Разность по производительности как у реализации первого DOOM, и современных портов, которые работают с графическими API.
Плюс это довольно бестолково - зачем забивать ядро процессора (или несколько ядер если многопоточно рендерить) кранчингом пикселей, когда есть специально обученное устройство для этого?
> Данные с CPU на GPU особо и не передаются.А композитинг как делать? Ну ладно, в частном случае, где используется встроенная графика, оно никуда не передаётся. Ибо видеопамять это просто кусочек RAM и при желании можно это дело разрулить без копирования.
Собственно на CPU всё ещё остаётся рендеринг отдельных глифов. Оно конечно переносится на GPU, но там свои проблемы с подобным. А так рендерим глифы в кеш и всё. А в случае терминала это работает очень хорошо ибо всегда один размер у глифов. Так что переполнение кеша может даже вообще не происходить в практичных сценариях использования.
На самом деле CPU рендеринг не то, чтоб прям медленный. CPU сейчас быстры. А вот пропускная способность памяти и пропускная способность всяких шин являются гораздо большим затыком для много чего. Вычисления часто бывают быстрее, чем чтения из памяти. Что кстати и для CPU и для GPU верно.
Хотя конечно очевидно, что рисование на GPU быстрее, чем на CPU. Просто именно вычислительная часть не является затыком. Задача рисования терминала сама по себе не прям какая-то вычислительно сложная.
Впрочем штуки, связанные с производительностью надо для начала измерять, там очень часто всякие неочевидные штуки вылезают. Особенно в этом плане меня радуют любители считать инструкции например. При том, что на синтетике можно даже получить строгий контрпример, когда добавление чего-то вроде nop может ускорить код. Даже не на всяких MIPS, где подобные приколы фича, а не баг.
вы че, обыкновенный терминальный текст через фреймбуфер на экране что ли отрисовываете?
> вы че, обыкновенный терминальный текст через фреймбуфер на экране что ли отрисовываете?Как у тебя там в волосатых восьмидесятых кстати?
> Меньше данных передаётся с CPU на GPU, а это основной затык производительности. Особенно если речь идёт о 4к мониках. Один фрейм полноэкранный это уже примерно 32 мегабайта на фрейм между прочим. Где-то 2-4 гигабайта в секунду в зависимости от фремрейта.Oh NOO!!! как же это все по модему-то передавалось раньше!
Речь идёт о рендеринге внутри _эмулятора_ терминала. Да, безусловно когда-то очень давно были "железные" терминалы, но они ОЧЕНЬ давно либо на свалках, либо в музеях
> Речь идёт о рендеринге внутри _эмулятора_ терминала. Да, безусловно когда-то очень давно
> были "железные" терминалы, но они ОЧЕНЬ давно либо на свалках, либо
> в музеяхминуту. то есть по модему информация передается. а внутри эмулятора у нас ОЧЕНЬ большие накладные расходы? так что ли выходит? чего мы рендерить-то с такой интенсивностью собрались.
Смотри. У нас разрешение допустим 3840×2160. Запускаем эмулятор терминала на весь экран. Это ровно 8 294 400 пикселей. Каждый пиксель полноцветный, то есть 4 бита на пиксель. Это получается 33 177 600 байтов. Обновляется у нас экран допустим базированные 60 раз в секунду. То есть один кадр рендерится 1/60 секунды, примерно 16.6 миллисекунд. Ну или 1 990 656 000 байтов в секунду.Это пиковая нагрузка. Мы рендерим на CPU, соответственно мы в этих условиях должны иметь возможность полностью с нуля за 1/60 секунды полностью отрисовать весь контент, который у нас есть. Мы текст превращаем в растровую графику же. Если напрямую без кеширования вообще это делать, то это будет ощутимо даже на современных CPU. Но дальше то после отрисовки нам это всё надо передать на GPU так или иначе. Этот буфер потом пройдёт через композитор (иксы, вяленый, не важно) и уже после полной компоновки отправится на монитор.
Или же мы можем посылать на видимокарточку не всё изображение целиком, а только индексы глифов и немного ещё разного. То есть между видимокартой и процем у нас достаточно модема. На карточке залить буфер контентом будет на порядки дешевле, специализированная железка же.
Забавно, что рисование на GPU по итогу ближе концептуально к тому, как это всё устроенно в случае, если у тебя есть железный терминал. Ты терминалу посылаешь только метаинформацию, а оно там само уже рисует у себя всё.
Такие дела
У меня есть возражения против этой логики. Даже, если мы рендерим на CPU, у нас операции рендеринга вынесены на GPU через 2D графические библиотеки. Так называемое 2D ускорение доступно человечеству с каменного века. Это включает кеширование глифов на видеокарте. Графический буфер и так будет сформирован средствами композитора, и это он определяет, какие аппаратные возможности есть для ускорения.Если предположить, что картинка меняется 60 hz, то задача, которую ты предлагаешь решать, это по сути 60hz видео. Ты вываливаешь большой буфер в терминал и 60 hz в секунду показываешь его листинг в very high res. Очевидно бессмысленная задача, потому что никакой пользователь не считывает буквы с такой скоростью. Даже сам пиксель монитора у тебя имеет время отклика 4-8 мс. И даже при таких цифрах видео 25 кадров дает мазню. Если у тебя в терминале будет происходить frame skipping и 80% кадров отбрасываться, это совершенно приемлемо с точки зрения чтения текста. Это приемлемо для медленных экранов, которые являются мейнстримом.
При этом у нас на терминале есть другие более важные задачи, создающие нагрузку на CPU. Взаимодействие с программой, ввод-вывод, например, более приоритетны.
> Формированием битмепа занимается видеокарта, а не эмулятор терминала. Информации для генерации изображения приходят заметно меньше. ... будет на порядки дешевле, специализированная железка же.
Вопрос, даст ли это на самом деле более быстрый терминал? Давай от теории обратимся к тестам.
So to be clear, I don't object by people using GPUs to render text. I only object to this rationale that it will result in so much faster terminals, because as you can see from the span of throughput numbers, while Kitty and Wezterm doesn't do too badly they're also nowhere near fastest.
* rxvt-unicode: 0.140s
* kterm: 0.2s
* kitty: 0.28s (GPU accelerated)
* xterm: 0.51s
* wezterm: 0.71s (GPU accelerated)
Так оно всё не для того, чтоб ты мог прочитать текст на скорости обновления монитора. А для того, чтоб работа этого всего ощущалась более плавно.> Даже, если мы рендерим на CPU, у нас операции рендеринга вынесены на GPU через 2D графические библиотеки. Так называемое 2D ускорение доступно человечеству с каменного века. Это включает кеширование глифов на видеокарте. Графический буфер и так будет сформирован средствами композитора, и это он определяет, какие аппаратные возможности есть для ускорения.
В данном контексте примерно это и подразумевается под рендерингом на GPU.
> В данном контексте примерно это и подразумевается под рендерингом на GPU.Ну, это даже в древних терминалах есть. А вот новые терминалы подразумевают замену Си кода для CPU на шейдеры для GPU. Поэтому в сабжевой новости про OpenGL и написано. Это как гном выходит. Если у тебя есть мощная видюха, он более-менее работает. Если ты вдруг поставил на сервер для запуска какой-то 2д программы, он тут же выжирает половину всех процессорных ядер и становится лагучим и неюзабельным, то есть перестает выполнять задачи 30-летней давности. Терминал для меня - это инструмент.
> Так оно всё не для того, чтоб ты мог прочитать текст на
> скорости обновления монитора. А для того, чтоб работа этого всего ощущалась
> более плавно.Тогда я из тех, кому это совершенно неважно.
> Если ты вдруг поставил на сервер для запуска какой-то 2д программыЭто очень нетипичное использование. С позиции разработчика отвечу.
Гуй предназначен для десктопов и только для них. Проблемы нетрадиционных меньшинств нас не интересуют. Если очень нужно, то занимайся этим сам в своём форке.
Ой ну все, "ненужно" подвезли! Домашний хомячок учит мир жить. Вот тебя, веб-мaкaкер с 1% на десктопе, не спросили, что нужно на серверах.
Если ты запускаешь гуй на серваке, то ты делаешь что-то не так. Единственная веская причина так делать - инфраструктура для автотестов гуя и туда имеет смысл пихать видяхи. Для всех остальных случаев гуй отрезается, если он есть. У меня нет идей, почему ты не можешь либо сервера с видяхами получить, либо гуй отрезать.> веб-мaкaкер
Если только ультимативно полностековый. Могу написать всё, включая ядро, драйвера, файловый стек, графический стек, сетевой стек, системный слой, базу данных, браузер и собственно скриптуху. При наличии бесконечного времени разумеется.
Запустил компиляцию какого-нибудь хромиума, там триллион строк в консоль выплёвывается. И скорость отрисовки начинает реально влиять на время компиляции.
А обязательно смотреть на эти строки? Может запустить в скрине и отдетачиться? Если уж хочется самому хром компилировать.
при конпеляции хромиума никаких миллионов строк нет
Да, только хардварный текстовый режим 40x25, только хардкор.
Он уже очень давно далеко не хардварный.
Чтобы потихоньку пушить в терминал картинки и видео и выкинуть веб на помойку
Там же написали - чтобы проводить синтетический тест по выводу гигабайтных файлов в терминал. Ведь это же так важно!
Хашимото после отхода от дел и сдачи своего предприятия МежБизМаш'у похоже повредился в уме. Ввязался в какую-то иррациональную поделку (и близко не сравнимую с прошлыми его достижениями как инженера) и радуется этому.
Удивительно то, что 50 лет назад для работы с терминалом было достаточно элетромеханического устройства на 1000 транзисторов. А современный терминал "требует" милиард транзисторов (сколько там сейчас минимум в видеокартах, честно, не слежу)... А делают оба посути одно и тоже. Ну современный делает это несколько быстрее. Но точно не в милион раз (кратно бюджету транзисторов) эффективнее.
> Удивительно то, что 50 лет назад для работы с терминалом было достаточно элетромеханического устройства на 1000 транзисторов. А современный терминал "требует" милиард транзисторовА телевизоры вообще на нескольких радиолампах работали!
А если серьезно, то "удивительно" тут только то, как люди вроде тебя объясняют все непонятные им вещи не своей некомпетентностью в технических вопросах, а тем, что все вокруг "повредились в уме".
А вот не нужно аналоговую и цифровую технику сравнивать. Я вам напомню что после распада СССР в получившихся странах эти компьютеры попилили на металл и как видим - кто-то до сих пор радуется. А вот европейцы и американцы строили. Помню новость как где-то в 2009 году построили. Знаете зачем? Чтоб делать физические опыты и эксперименты для которых цифровая техника не проходит. Т.е. для науки, для физиков. Так-что смешного мало. Они наверняка понимали что делали, а до кого-то не доходит и до сих пор как это применять.
например https://habr.com/ru/articles/406299/
десяток транзисторов, ага, да-да, но есть нюанс.
Ну нет, не по этому. Если ты можешь отрисовать весь полноэкранный эмулятор терминала не более чем за время вывода одного кадра, то это значит, что у тебя ни при каких условиях нет пропуска кадров. Нет задержек. В виме немного комфортнее сидеть.А ещё бонусом получаем лучшую энергоэффективность. Впрочем это важно только для ноутбуков.
> Ну нет, не по этому. Если ты можешь отрисовать весь полноэкранный эмулятор терминала не более чем за время вывода одного кадра, то это значит, что у тебя ни при каких условиях нет пропуска кадров. Нет задержек.Вы в серьез верите в то, что в окне терминала происходит что-то такое что не сможет отрисовать средний современный ПК (примерно 4 ядра 4Гц, 16Гб RAM) на CPU за 17милисекунд?
Вы не вкурсе что на компукторах середины 90х на CPU люди вообще играли в игры? Warcraft/starcraft, civilization и т.д., где много мелких деталей на экране (не говоря о нагрузке от самой игры), гораздо больше чем в терминале.>В виме немного комфортнее сидеть.
В виме намного комфортнее сидеть - если отключить тормозящие плагины. Уровень тормозов от эмулятора терминала и от плагинов посто несоизмерим. Это порядки.
> Вы в серьез верите в то, что в окне терминала происходит что-то такое что не сможет отрисовать средний современный ПКМожет, вполне может. Просто лично мне есть чем занять CPU помимо отрисовки терминала. Например если я из терминала наблюдаю за логами компиляции проги на расте.
> Вы не вкурсе что на компукторах середины 90х на CPU люди вообще играли в игры? Warcraft/starcraft, civilization и т.д., где много мелких деталей на экране (не говоря о нагрузке от самой игры), гораздо больше чем в терминале.
Более чем. Я ещё и знаком с программированием графики в контексте игр и UI. В частности знаком с нюансами того, как работает векторная/растровая 2D графика на CPU/GPU. А ещё у меня есть калькулятор. Он говорит, что мне требуется в 25-150 раз больше производительности (или пропускной способности) для того, чтоб аналог нарисовать в современных реалиях. И это я просто посчитал количество пикселей на единицу времени. Окей, местами скорость вычислений подросла даже больше. Но вот с пропускной способностью памяти так не произошло.
Если хочется конкретный пример вычислений: (3840*2160 * 60) / (640*480 * 30) = 54
Опять же рисовать на GPU более энергоэффективно. Это важно для ноутбуков.
С моей точки зрения получается, что вам выкатили объективно более производительную штуку, а вы почему-то ноете.
Затем же зачем использование GPU в браузере. Для ускорения отрисовки.
Затем же зачем software rendering, GPU rendering.
Тогда предлагаю, давайте сразу терминальный текст в браузере отрисовывать!
Зачем все эти полумеры?
Тогда предлагаю, давайте сразу терминальный текст в браузере отрисовывать!
Зачем все эти полумеры?
> Может кто пояснить зачем гпу для эмулятора терминала?За тем же, что и в любом другом случае вывода графики: для ускорения отрисовки и снижения нагрузки на CPU.
С уважением, ваш капитан.
Это пишется для отладки алгоритмов.
В современном мире программирования, есть большая проблема, распараллелить задачу на несколько процессоров. Для обычных, процедурных ЯП, это довольно сильный геморой, так как данные могут изменять несколько потоков. В функциональных ЯП, типа haskell, с этим все гораздо проще, проблема есть только на уровне железа https://habr.com/ru/articles/505356/ Если коротко, то удобнее разбить программу на отдельные, небольшие самодостаточные части. Такая программа хорошо параллелится на несколько процессоров. Как только процессор выполнил задание, он получает новое и т.д. Здесь не нужны мощные процессоры, гораздо важнее их колличество. GPU хорошо подходит для опытов )
> Может кто пояснить зачем гпу для эмулятора терминала?Чтобы не выполнять на стороне CPU операций, с которыми GPU справляется лучше. Замостить прямоугольник окна прямоугольными текстурами символов -- это пример задачи, на которую GPU заточен. С учётом всех нюансов, типа возможности скролла. Выполнять её на CPU это извращение.
Ага. Дожили. Без ГПУ теперь и буковки не вывести))).
>Для построения интерфейса в сборках для Linux задействована библиотека GTKЛучше Konsole всё равно ничего не было и нет.
> Лучше Konsole всё равно ничего не было и нет.Yakuake =)
guake
quake
doom в терминале
Зачем Doom, когда можно Spacemacs?
yakuake - это и есть konsole, только вид сбокуона использует konsole-kpart
Лучше может и есть. Но тратить время на поиски и переучивание и проблемы интеграции в систему большинству людей не нужно, если это не админ или devOps которые очень много работают в командной строке.
Вряд ли админу или девопсу нужно в реальном времени километры логов читать. 99% операций в терминале с медленным выводом. А там, где он быстрый, ты не успеешь ничего прочитать.
Вот зачем делать cat на громадный файл? Чтобы что?
Безголовые безгуёвые сервера управлят.
Службы качат, служды запускат.
Рееанимацие, ssh делайт.
Нескриптуемые операции вывод читат.Ну и еще, чем там админы занимаются после деплоя и первоначального запуска в режиме maintenance? Современный софт - это вам не сказ про замурованную в стену БЗДю
Это нужно не для чтения последовательности логов, а чтобы ввод-вывод плавнее работал при работе с консольными интерфейсами. Всякие vim, curses-морды, и т.д.
>Чтобы что?Чтобы перед ним написать time и обрадоваться насколько все стало быстрее.
Ты что, не рад этому?
Хорошо жить в своём воображении.
> Критикуешь - предлагай
Не очень понятно вообще что за фантазии про «лучше эмулятор терминала/хуже эмулятор терминала». Все они работают и предоставляют то для чего созданы. Я юзаю sakura и он ничем не лучше и не хуже Konsole или еще какой фигни
>Я юзаю sakura и он ничем не лучше и не хуже Konsole или еще какой фигниТвоя sakura тормоз еще тот. К примеру, запусти vifm или mc и в папке с множеством файлов зажми стрелку вниз. Увидишь, что в sakur-е "курсор" перепрыгивает через строчку. А, к примеру, в foot отображает курсор на каждой строке.
Тебе, естественно, все это пофигу, если ты, вероятнее всего, заглядываешь в консоль раз в год. А тем кто работает с ней постоянно, просто напросто, не комфортно работать с такими тормозами.
> Лучше Konsole всё равно ничего не было и нет.Konsole хорош, но только с KDE. Под другие окружения плохо оптимизирован.
urxvt
а он truecolor поддерживает? Я помню он мне не зашёл, а почему не помню.
> Лучше Konsole всё равно ничего не было и нет.foot
Быстрее стартует, быстрее выводит, жрёт меньше памяти, не требует тянуться к мыши для открытия ссылки, не зависит от KDE.
Там на хабре (простите, натуралы) болгарин прогу сразу под иксы написал, без xcb (не то что гтк) и получил высокую производительность интерфейса.
А ткт gpu для терминала.
Можно, пожалуйста, линк или название? Интересно
у него там кроссплатформенная IDE на FASM, под линукс подключается напрямую к X-серверу без библиотекhttps://habr.com/ru/articles/784282/
у него же есть статья "Как работает протокол X11 на самом нижнем уровне"
https://habr.com/ru/articles/712376/
фу таким быть. Интел и Амд не одобряют
`В терминале могут отображаться emoji, гиперссылки, сложные графемы и лигатуры (слияние нескольких символов в один, например, "æ").` - он что решил harfbuzz переписать?В нормальных местах аппаратно-ускоренный вывод текста делается через DirectWrite и вообще не забота писателей терминалов.
жалко, что в тех местах написание терминалов тоже не забота писателей терминалов
windows terminal же есть. И он хорош.
Скажите там кто-нибудь монстрософту, что ConEmu изобрели гораздо раньше wt.
Windows Terminal - отличный. И отрисовывает всё в миллион раз быстрее iTerm-а кстати. Тут коллега недавно запустил команду, выводящую (случайно) что-то около 60-ти тысячи строк в этом своём айтерме на макоси. Ctrl+C не работает, сидел ждал отрисовки минимум минуту, а то и дольше. У меня тоже самое через Windows Terminal в WSL завершилось за 3 секунды.Такие они, макофилы и винданенавистники.
> 60-ти тысячи строк
> через Windows Terminal в WSL завершилось за 3 секунды.Кек. Я как раз сейчас отлаживаю код, который имеет внутре 10k итераций цикла. При этом я гоняю эти 10k итераций трижды на разных входных последовательностях. И если я добавляю один println в цикл, то получаю 30k строк на экране. Часто я добавляю больше, чем одну строку на итерацию, вплоть до пяти. Alacritty прожёвывает не моментально, потому что на глаз видна разница в скорости выполнения между выводом в консоль и перенаправлением в файл, но 3 секунды на это? Не, это много.
Если вендовс терминалу требуется 3 секунды на 60k строк, то это отстой, а не терминал. То есть, ок, бывают медленее, я согласен, то есть вендовс терминал -- не самое днище. Но 3 секунды на 60k строк это много. А если их будет не 60k, а 600k?
Идеальный терминал должен прожовывать вывод в него со скоростью, которая ограничена сверху сисколлами: моя программа дёргает сисколлы на каждый println, это медленно, вот это "медленно" должно быть нижней планкой для скорости терминала, всё что ниже -- это не идеал. Alacritty тоже не дотягивает до этого идеала, но терминалов уровня alacritty мало, их можно на пальцах пересчитать, и windows terminal, судя по твоему описанию, в их число не входит.
> Если вендовс терминалу требуется 3 секунды на 60k строк, то это отстой, а не терминал.Время отработки имеет смысл сравнивать только на одной и той же логике, на одном и том же железе. Иначе непонятно, что именно ты измеряешь.
В том сценарии внутри этих трёх секунд происходило дофигища логики по преобразованию и форматированию данных. Это не время работы cat.
Поэтому и говорится, что в iterm 60 sec, в Windows Terminal 3 sec. Что бы их можно было сравнить, т.к. делали они одно и то же.
А, не, слушай, я наврал. Я трижды прогоняю алгоритм, и если два раза он на искусственно сгенерированных последовательностях char'ов по 10k каждый, то третий раз он прогоняется по тексту книжки. Книжка детская, небольшая по объёму, но в ней 460k байт, или, надо полагать, где-то около 200k utf8-символов.
А разве gtk не работает отрисовывает свой интерфейс через opengl? Может кто то пояснить в чем новшество
>В проведённых тестах Ghostty оказался быстрее эмуляторов терминала iTerm и Kitty в 4 раза, а Terminal.app - в 2 раза, при выводе на экран содержимого большого файла, например, при помощи команды "cat big_file.txt"Целый новый проект для оптимизации уже давно существующих решений по абсолютно бесполезному параметру
там проекты на zig, rust, go и objective-c, логика в принципе отдыхает
Главное, что терминал этот не работает внутри электрона.
Или в следующем мажорном релизе таки поправят это вопиющее недоразумение?
не знаю про zig, но можно переписать на nim, он транслируется в js
Domterm посмотри.Написан на Kawa Scheme.
+1. Использую рисующий на CPU foot, вообще ни одной претензии.
Судя по сравнениям под Linux его собрали чисто случайно.
А смысл огромный файл без less открывать?
никогда случайно не cat-ал гигантский бинарник?
Зачем его быстро выводить? И открой для себя ctrl+c.
ctrl+c не работает, если ты катнул гигантский файл в медленном терминале/на медленном соединении, гений
А за это спасибо погромистам, которые не к месту непропорционально большие буферы воткнули.
Но перед этим придётся возможно несколько секунд подождать прежде чем ^C сработает
sixel-графику поддерживает?
> sixel-графику поддерживает?это вряд-ли... вот zigxel-графику — это запросто!
https://github.com/ghostty-org/ghostty/discussions/2496
> sixel-графику поддерживает?Было бы умно с их стороны, но они решили зачем то пойти другим путем
> непосредственно в терминале может использоваться протокол Kitty.
Автар которого, безкультурный нарцизтический хам
а разве kitty умеет в графику?
> а разве kitty умеет в графику?
Это скорее всего не тот китти о которым вы подумали.
Это КовидГояловский китти, у него там много чего интересного наворочено в терминале, со своими собственными пониманиями карточных игр и женщинами без социальной ответственности.
> Это скорее всего не тот китти о которым вы подумали.
> Это КовидГояловский китти, у него там много чего интересного наворочено в терминале,
> со своими собственными пониманиями карточных игр и женщинами без социальной ответственности.В точку ! Чел решил что пуп земли вместо интеграции с другими решениями
>переключение между сеансами при помощи вкладок.Может кто-нибудь объяснить ЗАЧЕМ делать вкладки, когда в каждом сеансе есть собственный терминал, между которыми легко переключаться.
Чтобы ты мог запустить 8 копий графического терминала.
В каждой копии программы - 32 вкладки.
На каждой вкладке - мультиплекстор вроде gnu screen
Внутри мультиплексора - по 3-4 отдельных сессии
>Чтобы ты мог запустить 8 копий графического терминала.
>В каждой копии программы - 32 вкладки.В чем проблема запустить 256 (=8*32) графических терминалов? Вкладки ЗАЧЕМ?
Чтобы было все в одном окне вяленого - и это все пока течёт твой любимый кетчуп!
Чтоб под каждую команду свой терминал. Чтобы не забыть вывод.
без шуток: что такое "сеанс" по-английски? не понимаю, о чём речьсессия?
Слово "сеанс" переводится на английский язык как session, хотя значение может немного варьироваться в зависимости от контекста.Примеры значений и контекстов:
Кинотеатр: Сеанс фильма — это время показа кинофильма. По-английски это будет movie session или screening.
Психотерапия: Сеанс психотерапии — это встреча пациента с терапевтом. По-английски это называется therapy session.
Тренажерный зал: Тренировочный сеанс — это занятие в тренажерном зале. По-английски это будет workout session.
Интернет-соединение: Сеанс подключения к интернету — это период времени, в течение которого пользователь подключен к сети. По-английски это internet session или online session.
Фотосъемка: Фотосеанс — это фотосъёмка, например, свадебная съемка. По-английски это photo shoot или photography session.Если ты имел в виду какое-то конкретное использование термина "сеанс", уточни, пожалуйста, контекст, и я смогу дать более точный ответ!
Ты чатгпт? Контекст выше, вот он:> Может кто-нибудь объяснить ЗАЧЕМ делать вкладки, когда в каждом сеансе есть собственный терминал, между которыми легко переключаться.
до сих пор пользуюсь xterm, единственная раздражающая вешь в котором — ломает текст при изменении размера терминала
А я ещё с телетайпа не слез, вот такого:
https://unixdigest.com/articles/the-terminal-the-console-and...
и главное, звоночек работает через терминал!
Тоже им пользуюсь почти всю жизнь, ломание текста не парит потому что просто всегда развернут на максимум
Расширенный протокол клавиатуры kitty поддерживается, надеюсь?
https://sw.kovidgoyal.net/kitty/keyboard-protocol/А то все устроили соревнования по скорости, которая вообще ни на что не влияет, а то, что использование приложениями горячих клавиш ограничено возможностями клавиатуры пишущей машинки 70х, всем типа норм. Даже консоль Винды лучше с клавиатурой работает :-/
Отвечаю сам себе: поддерживается. Круто. Молодцы.https://github.com/ghostty-org/ghostty/blob/e3b6bb71a051f572...
Я наверное не терминалю столько чтобы интересоваться скоростью отрисовки "cat bigfile".
А они в версии 2.0 выкатят поддержку 3D в терминале? Как раз не хватает.
> А они в версии 2.0 выкатят поддержку 3D в терминале? Как раз не хватает.Еще реквестирую возможность покупки премиума с платными анимированными эмоджи и возможностью закрепить более 5 вкладок.
Джва года жду такой терминал.
За 20+ лет на линухе ни разу не сталкивался с проблемой медленного ввода/вывода текста в консольных терминалах. Может юзаю неправильно?
скорее наоборот, как раз правильно. Я вот тоже раньше не сталкивался, пока с мыслю «Все терминалы одинаковы» не запустил чертов гном терминал.Бывало когда нибудь что нажимаешь кнопку в приложении или на сайте, а кнопка под рукой меняется. Вот такие же ощущения. Пришлось sh(из BusyBox который) включать, что бы хоть как то работать.
> За 20+ лет на линухе ни разу не сталкивался с проблемой медленного ввода/вывода текста в консольных терминалах.Ни разу не комплировал ничего в консоли? Может ты вообще ни разу ничего не компилировал? Когда у тебя бутылочным горлышком компиляции оказывается терминал, ну это так себе.
Плюс если ты программы пишешь, то бывают ситуации, когда приходится использовать тысячи отладочных printf'ов, и в этих ситуациях тормознутость терминала может одолеть даже тормознутость отладочной сборки.
Если ты и компилировал, и отладочным выводом злоупотребляешь, то единственное объяснение возможное тому факту, что ты не замечал медленного вывода это то, что ты просто никогда не видел быстрого.
Отладочный вывод в консоль использую. Даже для Win писал свой вариант.
Но там как? Пришло в лог например 30кб данных, но в окне можно отобразить только 4кб последних данных, и вот только оно и рисуется. ;)А уж скорость с которой консоль принимает данные, никак не связана со скоростью их отрисовки.
Таким образом скорость отрисовки 10кБ и 1Гб, при выводе одной порцией, типа команды cat, примерно одинакова, и зависит только от быстродействия процессора и памяти, но не от скорости отрисовки.
Прочёл на сайте фразу "Building Ghostty from source is not recommended for most users".
Стало интересно, соберётся ли эта штука под убунтой 22.04.
Делал в виртуалке — качнул zig, установил указанные зависимости. Собралось влёт, запустил прямо из каталога сборки, работает. Выглядит стрёмненько, диалога настроек нет, при запросе пароля sudo рисует иконку с замочком.Перекинул весь каталог сборки из виртуалки в рабочую систему (та же убунта 22.04) — запускается, но пишет "file not found" и сразу завершается. Какой файл оно not found — не сообщает. Ну и ладно, не очень-то и хотелось.
Если запускается через шелл скрипт, то file not found указывает как раз на отсутствие файла в первой строке - #!/bin/bash
Не, я его из терминала запускал, оно запускается, пишет в консольку всякую отладочную инфу, типа "использую OpenGL", "gtk версия такая-то", "libadwaita версия такая-то", а потом пишет "error: File not found" и выходит. А в виртуалке потом пишет версию opengl и работает дальше.
Разбираться не стал, ну его.
А каков терминал по потреблению памяти? Интересуют показатели RES и SHR из top.
Вот, top запущен прямо из ghostty, для максимальной аутентичности.) Процессы отсортированы по %MEM.
https://imgur.com/Wd6xG5gЖрёт прилично, и проц жрёт, хотя может это из-за того, что виртуалка, следовательно opengl софтверный. Хотя тормозов не особо заметно.
Ого! 200 и 100 мегабайт соответственно! Для терминала, мягко говоря, многовато.
хех, он у вас там что, биткоины майнит через видеокарту что ли?
Так, установил на реальную машину дев-либы и оно заработало на реальной машине.
Памяти жрёт поменьше и проц почти не жрёт.
Тоже столкнулся с этим. Не хватало libx11-dev
> для Linux задействована библиотека GTKQt использовать честь не позволила?
qt на плюсах, их на маргинальных языках типа zig или раст не заюзаешь
Да почему, уже есть биндинги.
биндингов навалом, ты с ними попробуй что-нибудь написатьпро поддержку qt в редакторах кода под эти языки я помолчу (хотя бы документации и подсветки синтаксиса, не говоря о qml)
Компилятор зига буквально компилирует C/C++, это как бы фича, але?
Вместо гугла коментарии опеннет открываются?
На HN 1500 плюсов. Здесь как обычно одно нытье. Стабильность.
INTERNET POINTS!!!! даже на HN still internet points.
ценность очередной поделки изменилась ровно... на 0. ЧСВ автора выросло. Для этого оно и создано.Вот когда наработки войдут во что-то нужное, тогда можно будет говорить как принимали на HN.
Возвращайся тогда, ОК.
Почитай что ли, кто автор софтины и нужно ли ему твоё чсв.
Если ты добьешься в своей жизни хотя бы 1/1000 от его достижений, это будет уже успех.
Глянул кто автор и чем известен
Теперь интересно зачем человеку такого масштаба писать 100500ый терминал
Видимо по приколу
Ну так Хашикорп деньги инвесторов съела, а своих зарабатывать толком не научилась. Лицензию сменили — всё равно не помогло. Ну вот теперь пытаются IBM продаться. Митчелл вон хобби нашёл, поеупатели видно деньгами не обидят, да и сам он человек не бедный, думаешь куда инвесторские бабки делись?
восхитились скилами олда? ок.ты так и не ответил зачем. слив защитан.
Что такое HN?Быстрый поиск не дал результатов
https://news.ycombinator.com/item?id=42517447HN - место откуда сюда тащат новости
> РЕДАКТИРОВАТЬ: ВАУ, для меня это изменит правила игры. Я просто работал над Redis, выводя тонны отладочной информации и результатов, и обычно терминал был узким местом, а здесь вместо этого он напечатал полмиллиона в мгновение ока результатов. И тогда я мог бы вернуться в историю без какого-либо ухудшения производительности. Мне это нравится: для разработки систем это имеет большое значение.Разумеется, эти полмиллиона строк он успел прочитать и осмыслить.
зачем иму их читать и тем более осмыслять. Например. Всё черно белое - не заморачиваемся работаем дальше. Мигнуло красное или последняя строка с ошибкой. Начинаешь читать с низу вверх
> Разумеется, эти полмиллиона строк он успел прочитать и осмыслить.О, опеннетные знатоки "разработки систем" подтянулись. Речь ведь о "system development"? Кстати, как знаток "разработки систем", ответь мне на вопрос почему ты считаешь, что правильнее переводить как "разработка систем", а не "системная разработка"?
>оказался быстрее эмуляторов терминала iTerm и Kitty в 4 раза, а Terminal.app - в 2 раза, при выводе на экран содержимого большого файла, например, при помощи команды "cat big_file.txt".на конкурсе хакиров получили приз из самой большой кеги с пивом. или что там зигшикам дают, банку смузи. трёхлитровую.
ЗЫ а чо с каким-нибудь gnome-terminal не сравнили, который сто лет как тупо проматывает вывод который никому не нужен в динамике? т.е. поступает разумно. Думаю не только он.
"при выводе на экран содержимого большого файла, например, при помощи команды "cat big_file.txt"Я надеюсь, пользователи, которые это тестировали, успевали его при этом прочитать?
Кстати сколько он FPS даёт?
> Кстати сколько он FPS даёт?По частоте обновления монитора, демонстрируя конец файла, и длинный скролл-бар?
Код проекта написан на языке Zig и распространяется под лицензией MIT.
Уж лучше бы на COBOL, как Майнкрафт-сервер из соседней новости. Зато его бы хоть можно было собрать GNU COBOL-ом.
Каждый терминал надо под себя подстроить и часто игра не стоит времени на нее затраченного. Лично я использую классику Xterm, urxvt kitty, alacritty, putty и все в линухе.
Собрал, поставил, работает хорошо. Системе сборки не хватает возможности ограничить количество ядер, очень много потоков при сборке жрало память. И логов бы еще хорошо, потому что полчаса zig build скачивал по медленному соединению какие-то зависимости. Проект хорош. Удивительно как zig несмотря на желание отделиться от LLVM, выпилить волшебный нормально работающий @cImport и сделать в будущем костыль в build.zig вместо этого пользуется популярностью у весьма интересных проектов, которые работают.
True X terminal: https://st.suckless.org/
Как он там, уже перестал корёжить вставку текста больше пары мегабайт? inb4 нинужна
Адепты suck тебе скажут "А нам это не надо"
Они про нормальные настройки, а не через переписывание исходников говорят "Это никому не надо", а ты про вставку текста. Им не надо
тебе надо - ты и пили, там исходников на пару сотен LOC
О чем я и предупредил сразу
>True X terminal: https://st.suckless.org/St идет лесом без поддержки вяленного.
> inputs = {
> nixpkgs-unstable.url = "github:nixos/nixpkgs/nixpkgs-unstable";Очередная блендингэдж разработка.
(Из репозитория github.)
> Compiled ok but crashed upon execution:...
> Also same issue. Seems it’s using a bleeding edge OpenGL ES that even nVidia drivers don’t support....
> You have OpenGL 3.2 but need 3.3...
> Error is a little misleading. OpenGL is likely much higher than 3.3 since op is using nvidia gpu.
>
> Problem is that this application uses OpenGL ES for which 3.3 was only recently even finalized as a standard and most GPUs like nvidia don’t support.
Чем отличается ES версия от обычного?
> использующего GPU для ускорения отрисовки содержимогоЗачем это нужно? Это же терминал, а не игра компьютерная. С чего в нем отрисовке тормозить?
у тебя веб браузер плавненько отображает страницы благодаря GPU, тоже не замечаешь? Люди любят, когда плавненько
у меня он плавненько отображает страницы, потому что я выключил анимации интерфейса и транзишны веб-страниц и порезал всё uBlock-омвремя рендеринга - ничто
> потому что я выключил анимации интерфейса
> и транзишны веб-страниц и порезал всё uBlock-омВеб-браузеры активно используют GPU и память видео карты, это можно увидеть утилитами отображающими загрузку GPU.
Вот если бы ты отключил аппаратное ускорение, GPU бы перестал использоваться, как и аппаратные кодеки.
> у тебя веб браузер плавненько отображает страницы благодаря GPU, тоже не замечаешь?Как связан браузер, в котором может отображаться сложная графика, с текстовым терминалом?
> Как связан браузер, в котором может отображаться сложная графика, с текстовым терминалом?И там и там GPU участвует в рендеренге UI. Или ты думаешь это для 3D веб-игр каких-нибудь? Нет
>> Как связан браузер, в котором может отображаться сложная графика, с текстовым терминалом?
> И там и там GPU участвует в рендеренге UI. Или ты думаешь
> это для 3D веб-игр каких-нибудь? НетЕще раз вопрос: зачем в сравнение приводить браузер, если мы говорим о терминале, в котором только текст отображается?
Сравнение с веб браузером только в том контексте, в котором он также рендерит тест и элементы UI, используя GPU.В Ghostty плавней скроллится текст на большом мониторе, это же просто приятно.
Вообще, кто вам вбил в голову странную мысль, что рендеринг, используемый в игровых движках, только для игр. Нет.
> что рендеринг, используемый в игровых движках, только для игр. Нет.Понятно, что нет. Видимо это мода такая, в редакторы кода тащат, теперь и в терминалы...
>> Как связан браузер, в котором может отображаться сложная графика, с текстовым терминалом?
> И там и там GPU участвует в рендеренге UI.UI в браузере - это html + css, что сама по себе сложная система со всякими позиционированиями и анимациями. В терминале просто текст и все. Зачем для текста все усложнять? Кому и с каких пор стал рендер текста в терминале тормозить?) Да, даже на супер старых компьютерах все летало.
>Кому и с каких пор стал рендер текста в терминале тормозить?)С тех пор, когда в терминале начали юзать проги с псевдографическим интерфейсом.
>>Кому и с каких пор стал рендер текста в терминале тормозить?)
> С тех пор, когда в терминале начали юзать проги с псевдографическим интерфейсом.ncurses? Не заметил никаких тормозов даже в tty
Чтобы вот так вот делать.
https://mitchellh.com/_next/image?url=https%3A%2F&...
> Зачем это нужно? [...] С чего в нем отрисовке тормозить?Для целесообразности задействования ускорения отрисовки не обязательно, чтобы до этого она прямо тормозила. Есть и другие причины, типа меньшей нагрузки на CPU и большего времени работы батареи ноутбука.
>> Зачем это нужно? [...] С чего в нем отрисовке тормозить?
> Для целесообразности задействования ускорения отрисовки не обязательно, чтобы до этого
> она прямо тормозила. Есть и другие причины, типа меньшей нагрузки на
> CPU и большего времени работы батареи ноутбука.А GPU внезапно работает не от батареи? Или потребляет меньше для данного случая? Замеры может есть какие?
> Или потребляет меньше для данного случая?Именно.
> Замеры может есть какие?
Какие тебе нужны замеры, если GPU - это железка буквально созданная и оптимизированная для рисования?
>> Или потребляет меньше для данного случая?
> Именно.Хотелось бы замеры увидеть.
>> Замеры может есть какие?
> Какие тебе нужны замеры, если GPU - это железка буквально созданная и
> оптимизированная для рисования?Обычные. Мы же про текст в терминале говорим. Пусть будет обычный терминал с отрисовкой на CPU и какой-либо на GPU. По замерам хотелось бы увидеть:
* скорость отрисовки
* потребление батареи, раз уж об это речь зашлаНо сдается мне, что вся эта котовасия с GPU потратит батарею уж точно больше, чем CPU рендер.
> Но сдается мне, что вся эта котовасия с GPU потратит батарею уж точно больше, чем CPU рендер.Я не знаю, с какого перепуга тебе это сдается, но при всех прочих равных GPU рисует быстрее, чем CPU. В этом как бы весь смысл существования GPU. Странно с этим спорить.
>> Но сдается мне, что вся эта котовасия с GPU потратит батарею уж точно больше, чем CPU рендер.
> Я не знаю, с какого перепуга тебе это сдается, но при всех
> прочих равных GPU рисует быстрее, чем CPU. В этом как бы
> весь смысл существования GPU. Странно с этим спорить.С чем спорить? Ну раз быстрее, то покажи замеры. Еще раз мы говорим про текст. С какого перепуга нужно тащить отрисовку через GPU туда?
GPY рисует растр. А текст там, смайлы или хентайная картинка — ему всё равно.
Замеры, нужны замеры. Хватит болтовни.
Бывают случаи, когда при отладке что-то выводится в окно терминала и тормозит процесс. Приходится через переопредление (> файл) ввода-вывода работать, но тогда трудно заметить что-то в процессе и/или прервать его. Если вывод будет чуть быстрее, не помешает. Пусть будет.
Лол, тормозит не из-за рендера, можешь свернуть терминал и измерить.Чуть быстрее? На 0.0000000000000001%? Ради этого тащить кучу кода с потенциальными уязвимостями?
Ну конфиги я еще для него не писал.
Тьфу, мракобесия
мракобесия это такой объём опций выносить в кнопки, выпадающие менюшки, табы. И мракобесие елозить мышькой по столу все их отмечая.
А конфиг в JSON, YAML, TOML, INI и т.п. формате править в одном из твоих любимых тестовых редакторов с подсветкой синтаксиса это милое дело, просто заглядение. Это красиво и мега удобно, особенно когда изменения мгновенно применяются.
У приложения должен быть разумный дефолт.
И не должно быть миллиона опций для каждой мелочи.
> У приложения должен быть разумный дефолт.
> И не должно быть миллиона опций для каждой мелочи.Разумный дефолт, как правило есть. По опциям бороздить, без необходимости, и не требуется. Изначально может пару тройку выставляешь, в остальные тебе и вникать не нужно. Я так Kitty настраивал, вникал в остальные только по мере необходимости.
> мракобесия это такой объём опций выносить в кнопки, выпадающие менюшки, табы. И
> мракобесие елозить мышькой по столу все их отмечая.
> А конфиг в JSON, YAML, TOML, INI и т.п. формате править в
> одном из твоих любимых тестовых редакторов с подсветкой синтаксиса это милое
> дело, просто заглядение. Это красиво и мега удобно, особенно когда изменения
> мгновенно применяются.Особенно "красива" поддержка всех этих форматов.
Сколько людей оказывается не видели в глаза терминал. Делается греп по исходникам, и попадается скомпилированный минифицированный js. Обычный терминал ужасно тормозит, из-за одной очень длинной строки. Или же запускается какой-то сервис, интенсивно пишущий логи. Опять же, обычный терминал тормозит. Таких примеров куча, но обладатели локалхоста их не узнают
как раз только на локалхосте такие проблемы и будут. по сети основной ботлнек - сеть
>по сети основной ботлнек - сетьУ вас до сих пор диалап? Достаточно по ssh подключится, современные сети позволяют передавать мегабайты достаточно быстро, чтобы терминалы тормозили.
> Автор Ghostty пытается воплотить в новом эмуляторе терминала <...> интерфейс, выглядящий родным для каждой поддерживаемой платформы
> в сборках для Linux задействована библиотека GTKАвтор провалился.
Meh. Alacritty запускается мгновенно, этот стартует c лагом где-то в 2-3 секунды и так каждое окно. Для сценариев работы с тайловыми wm нежизнеспособно
Я бы даже назвал такое ПО мертворожденным.
Сейчас, ещё надо еще удриться найти столь лагающее при запуске ПО.
>в сборках для Linux задействована библиотека GTK
>что позволило использовать штатные для каждой платформы диалоги, меню, интерфейс для изменения настроек и стилизацию оконОхренеть.
>>быстрее.. при помощи команды "cat big_file.txt".Бесполезный тест. Поскольку чтение заведомо не предполагается, можно провести оптимизацию, выводить с потерями, которые не заметят, и поднять скорость на порядки. ;)
Плюс, если именно так, то очень, очень хорошо работают буферизации.
Гламурненько так. Пользователям Мак понравится. Но чем больше в программе рюшечек, тем меньше безопастность. Линуксоиды не купятся.
> Гламурненько так. Пользователям Мак понравится. Но чем больше в программе рюшечек, тем
> меньше безопастность. Линуксоиды не купятся.На поделку Поттеринга купиилсь же.
Очевидно же, что чел просто хотел поиграться с зигом. Всерьёз это рассматривать нет смысла.Быстрый терминал уже есть - alacritty - и в отличие от, под все платформы.
Откройте для себя kitty, alacritty даже близко не валялся.