Terminal: Печатать в терминале WSL по умолчанию просто потрясающе, почему это лучше, чем любое другое приложение?

Созданный на 14 дек. 2018  ·  8Комментарии  ·  Источник: microsoft/terminal

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

При вводе в терминале WSL по умолчанию создается впечатление, что вы печатаете в эфире. В этом есть плавность, которой нет ни в одном другом приложении Windows, даже в notepad.exe . Если кажется, что у него задержка ввода 10 мс вместо 75 мс + для всех других Windows (и 200-250 мс + для большинства приложений на базе Electron).

Что делает терминал WSL лучше, чем notepad.exe и появится ли это улучшение пользовательского интерфейса во всех приложениях Windows в будущем?

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

Issue-Question Product-Conhost

Самый полезный комментарий

Я действительно не против, когда кто-то приходит и решает сказать нам, что мы в чем-то хорошо работаем. Каждый день мы слышим столько жалоб, что такой пост - глоток свежего воздуха. Спасибо за вашу благодарность!

Кроме того, я буду рад обсудить это с вами, пока вам не надоест читать. Пожалуйста, задавайте любые вопросы, которые вам нужны. Мне нравится болтать о своей работе. :П

Если бы мне пришлось сделать обоснованное предположение о том, что заставляет нас быстрее, чем любое другое приложение в Windows выводить ваш текст на экран ... Я бы сказал, что это потому, что это буквально наша единственная работа! Также, вероятно, потому, что мы чертовски используем API самого старого и самого низкого уровня, которые Windows должна выполнить для этой работы.

Практически все остальное, что вы перечислили, имеет какой-то уровень или структуру, или много, много слоев и структур, когда вы начинаете говорить об Electron и Javascript. Мы этого не делаем.

У нас есть одно голое, совершенно не особенное окно, к которому не прикреплены дополнительные элементы управления. Мы получаем наши ключи чуть выше ядра, учитывая, что мы обрабатываем их из оконных сообщений, а не из какой-то среды обработки событий, общей для практически любой другой более сложной инфраструктуры пользовательского интерфейса, чем наша (WPF, WinForms, UWP, Электрон). И мы выгружаем наш текст прямо на поверхность окна с помощью GDI PolyTextOut без каких-либо излишеств.

Даже notepad.exe имеет, по крайней мере, несколько элементов управления в своем окне и, вероятно (я не смотрел), использует какую-то библиотечную структуру в элементе управления редактирования, чтобы выяснить его текстовый макет (который, вероятно, использует другую библиотеку рамки для поддержки интернационализации ...)

Конечно, это также означает, что у нас есть компромиссы. Мы не поддерживаем полностью международный текст, как почти все другие приложения. RTL? Запретная зона прямо сейчас. Суррогатные пары и смайлики? Мы приближаемся, но еще не достигли цели. Индийские скрипты? Нет.

Почему мы такие? Во-первых, conhost.exe стара как грязь. Он должен использовать голый металлический нижний слой всего, потому что он был создан до того, как были созданы большинство других фреймворков. Кроме того, он поддерживает как можно более низкий / нижний уровень, потому что это в значительной степени первое, что нужно поднять при создании новой версии операционной системы или устройства, прежде чем у вас будут все приятные вещи, такие как фреймворки или то, что эти фреймворки требуют для работать. Кроме того, он написан на C / C ++, который настолько низок и чист, насколько это возможно.

Будет ли это улучшение пользовательского интерфейса распространено на другие приложения в Windows? Почти наверняка нет. У них слишком много всего, что и хорошо, и плохо. Я завидую их способности просто вызвать один метод и разметить текст несложным образом на любом языке, не вычисляя вручную пиксели и не заботясь о том, какие стили применяются к их шрифту. Но мои ручные вычисления пикселей, математика с грязными областями, безумие областей прокрутки и многое другое позволяют нам работать быстрее, чем они. Я также завидую, что, когда кто-то говорит: «Эй, вы можете добавить строку состояния в нижнюю часть окна?», Они могут щелкнуть и перетащить ее на место с помощью своей UI Framework, и это будет работать там, где, как для нас, это всегда оставался невыполненным и заставлял меня думать о реализации.

Будем ли мы пытаться предотвратить его регресс? Да! Сейчас это своего рода ручной процесс. Мы определяем, что что-то замедляется, а затем вытаскиваем WPR и начинаем отслеживать. Мы смотрим на горячие пути и пытаемся понять, что происходит, а затем улучшаем их. Например, в последнем или двух циклах мы сосредоточились на распределении кучи как основной области, где мы могли бы улучшить нашу сквозную производительность, изменив тонну нашего кода, чтобы использовать фасады, построенные на основе стека итераторов, над базовым запросом. buffer вместо того, чтобы переводить и выделять его в новое пространство кучи для каждого уровня обработки.

Кстати ,

Если вы хотите узнать что-нибудь еще, дайте мне знать. Я мог бы продолжать весь день. Я удалил около 15 касательных из этого ответа, прежде чем публиковать его ....

Все 8 Комментарий

Я действительно не против, когда кто-то приходит и решает сказать нам, что мы в чем-то хорошо работаем. Каждый день мы слышим столько жалоб, что такой пост - глоток свежего воздуха. Спасибо за вашу благодарность!

Кроме того, я буду рад обсудить это с вами, пока вам не надоест читать. Пожалуйста, задавайте любые вопросы, которые вам нужны. Мне нравится болтать о своей работе. :П

Если бы мне пришлось сделать обоснованное предположение о том, что заставляет нас быстрее, чем любое другое приложение в Windows выводить ваш текст на экран ... Я бы сказал, что это потому, что это буквально наша единственная работа! Также, вероятно, потому, что мы чертовски используем API самого старого и самого низкого уровня, которые Windows должна выполнить для этой работы.

Практически все остальное, что вы перечислили, имеет какой-то уровень или структуру, или много, много слоев и структур, когда вы начинаете говорить об Electron и Javascript. Мы этого не делаем.

У нас есть одно голое, совершенно не особенное окно, к которому не прикреплены дополнительные элементы управления. Мы получаем наши ключи чуть выше ядра, учитывая, что мы обрабатываем их из оконных сообщений, а не из какой-то среды обработки событий, общей для практически любой другой более сложной инфраструктуры пользовательского интерфейса, чем наша (WPF, WinForms, UWP, Электрон). И мы выгружаем наш текст прямо на поверхность окна с помощью GDI PolyTextOut без каких-либо излишеств.

Даже notepad.exe имеет, по крайней мере, несколько элементов управления в своем окне и, вероятно (я не смотрел), использует какую-то библиотечную структуру в элементе управления редактирования, чтобы выяснить его текстовый макет (который, вероятно, использует другую библиотеку рамки для поддержки интернационализации ...)

Конечно, это также означает, что у нас есть компромиссы. Мы не поддерживаем полностью международный текст, как почти все другие приложения. RTL? Запретная зона прямо сейчас. Суррогатные пары и смайлики? Мы приближаемся, но еще не достигли цели. Индийские скрипты? Нет.

Почему мы такие? Во-первых, conhost.exe стара как грязь. Он должен использовать голый металлический нижний слой всего, потому что он был создан до того, как были созданы большинство других фреймворков. Кроме того, он поддерживает как можно более низкий / нижний уровень, потому что это в значительной степени первое, что нужно поднять при создании новой версии операционной системы или устройства, прежде чем у вас будут все приятные вещи, такие как фреймворки или то, что эти фреймворки требуют для работать. Кроме того, он написан на C / C ++, который настолько низок и чист, насколько это возможно.

Будет ли это улучшение пользовательского интерфейса распространено на другие приложения в Windows? Почти наверняка нет. У них слишком много всего, что и хорошо, и плохо. Я завидую их способности просто вызвать один метод и разметить текст несложным образом на любом языке, не вычисляя вручную пиксели и не заботясь о том, какие стили применяются к их шрифту. Но мои ручные вычисления пикселей, математика с грязными областями, безумие областей прокрутки и многое другое позволяют нам работать быстрее, чем они. Я также завидую, что, когда кто-то говорит: «Эй, вы можете добавить строку состояния в нижнюю часть окна?», Они могут щелкнуть и перетащить ее на место с помощью своей UI Framework, и это будет работать там, где, как для нас, это всегда оставался невыполненным и заставлял меня думать о реализации.

Будем ли мы пытаться предотвратить его регресс? Да! Сейчас это своего рода ручной процесс. Мы определяем, что что-то замедляется, а затем вытаскиваем WPR и начинаем отслеживать. Мы смотрим на горячие пути и пытаемся понять, что происходит, а затем улучшаем их. Например, в последнем или двух циклах мы сосредоточились на распределении кучи как основной области, где мы могли бы улучшить нашу сквозную производительность, изменив тонну нашего кода, чтобы использовать фасады, построенные на основе стека итераторов, над базовым запросом. buffer вместо того, чтобы переводить и выделять его в новое пространство кучи для каждого уровня обработки.

Кстати ,

Если вы хотите узнать что-нибудь еще, дайте мне знать. Я мог бы продолжать весь день. Я удалил около 15 касательных из этого ответа, прежде чем публиковать его ....

Говоря о низкоуровневых API-интерфейсах Windows, я обнаружил, что все компоненты _user mode_ как консоли (conhost.exe, cmd.exe ...), так и WSL (wsl.exe, LxssManager.dll ...) в огромной степени используют C ++ _STL_. Например, при манипулировании строками, распределении памяти, виртуальных таблицах и т. Д. Будет ли улучшение производительности при использовании только C?

Я бы не стал считать, что они используют C ++ STL «чрезмерно». Они определенно используют некоторые коллекции и, возможно, немного манипуляций со строками и алгоритмы здесь или там. Я чувствую, что STL - это гораздо больше, чем эти несколько бит.

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

Безопасность на самом деле является главной причиной, по которой мы используем шаблоны STL, а не пытаемся создать наши собственные структуры, когда это возможно. Использование шаблонов STL для коллекций и строк обычно предоставляет нам проверку границ, которая в противном случае должна была бы выполняться вручную, подверженной ошибкам (или не выполняться вообще!)

Также я не совсем уверен, что наличие 17 различных реализаций очередей и связанных списков внутри кода консоли, когда он был прямым C, был в целом лучше для производительности, чем использование std :: queue и std :: list сегодня. Вероятно, он потреблял больше места на диске для каждой отдельной реализации, что является проблемой производительности другого типа (хранилище и ввод-вывод загрузки страницы).

Спасибо, что нашли время написать этот ответ, и никаких проблем с похвалой.

Последние пару месяцев я искал хороший терминал и думаю, что ubuntu.exe с tmux настолько близок к совершенству, насколько вы можете получить с инструментами, которые у нас есть сегодня. Сам терминал ubuntu.exe очень быстро, а tmux дает вам все необходимое (вкладки, разделенные панели, поиск в буфере и т. Д.).

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

@miniksa : Спасибо за очень интересный пост!

мы чертовски используем API самого старого и самого низкого уровня, которые Windows должна выполнять для этой работы.

Какое-то время меня это интересовало. Похоже, вы имеете в виду различные API Win32 (USER32 / GDI32). В последнее время я не уверен в том, являются ли они по-прежнему столь же низкоуровневыми, как в последних версиях Windows (8.0 и новее), или же эти API-интерфейсы были незаметно преобразованы для использования поверх других вещей (таких как Direct2D, DirectWrite и т. Д.). Как старые API соотносятся с новыми? Я был бы рад, если бы вы могли прояснить этот момент!

@stakx , я имею в виду USER32 и GDI32.

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

Для графической части конвейера (GDI32) части GDI для пользовательского режима находятся довольно далеко вниз. Приложение вызывает GDI32, некоторая работа выполняется в этой DLL на стороне пользовательского режима, затем вызов ядра переходит к ядру и происходит отрисовка.

Часть, о которой вы думаете относительно «тихого преобразования, чтобы сидеть поверх других вещей», вероятно, заключается в том, что как только мы попадаем в вызовы ядра, связка материалов GDI ядра имеет тенденцию быть повторно преобразована поверх того же материала, что и DirectX, когда он фактически обрабатывается NVIDIA / AMD / Intel / и т. Д. графический драйвер и графический процессор в нижней части стека. Я думаю, что это произошло с измененной архитектурой графического драйвера, которая появилась как часть WDDM для Windows Vista. Где-то есть документ о том, какие вызовы по-прежнему очень быстрые в GDI, а какие медленнее из-за переплатформенности. В прошлый раз, когда я нашел этот документ и проверил, мы использовали быстрые.

Я считаю, что помимо GDI есть такие вещи, как Common Controls или comctl32.dll, которые предоставляли людям многоразовые наборы кнопок и элементов для создания своих пользовательских интерфейсов до того, как у нас появились более приятные декларативные структуры. На самом деле мы не используем их в консоли (за исключением окна свойств в контекстном меню).

Что касается DirectWrite, D2D, D3D и DXGI, они представляют собой отдельный набор команд и путей, которые полностью отделены от GDI как в пользовательском режиме, так и в режиме ядра. На самом деле они не связаны между собой, кроме того, что между ними есть некоторые положения о совместимости. Однако большинство других наших UI-фреймворков, как правило, строятся на основе стека DirectX. XAML точно. Я думаю, что WPF есть. Не уверен насчет WinForms. И я считаю, что стек композиции и оконный менеджер также используют DirectX.

Что касается части конвейера ввода / взаимодействия (USER32), я обычно обнаруживаю, что большинство других новых вещей (по крайней мере, для настольных ПК) построены поверх того, что уже есть. Основная концепция USER32 - это окна и дескрипторы окон, и все отправляется дескриптору окна. Пока вы находитесь на настольном компьютере (или ноутбуке, или о чем-то еще ... я имею в виду машину под управлением Windows в классическом стиле), задействован дескриптор окна и перемещаются сообщения, а это означает, что мы говорим о USER32.

Очередь оконных сообщений - это просто прямой FIFO (более или менее) любого ввода, имеющего отношение к этому окну, пока оно находится на переднем плане + все, что было отправлено в окно другими компонентами в системе.

Новые технологии и платформы, такие как XAML, WPF и WinForms, имеют тенденцию тем или иным способом получать сообщения из очереди оконных сообщений, обрабатывать их и превращать в обратные вызовы событий для различных объектов, которые они подготовили в своем мире.

Однако более новые технологии, которые также работают на других не настольных платформах, таких как XAML, как правило, имеют возможность обрабатывать данные из совершенно другого стека, отличного от USER32. Для USER32 есть отдельный параллельный стек со всеми нашими нововведениями и реализациями того, как должны происходить ввод и взаимодействие, что не совсем так, как с классическими очередями обмена сообщениями и обработчиками окон. Это все семейство вещей Core *, таких как CoreWindow и CoreMessaging. У них также есть другая концепция «что есть пользователь», которая не так сосредоточена на вашей заднице, когда вы сидите в кресле на колесиках перед экраном с клавиатурой и мышью на столе.

Теперь, если вы используете XAML или одну из других фреймворков ... вся эта сложность выполняется за вас. XAML выясняет, как использовать DirectX для вас, и договаривается с композитором и оконным менеджером о крутых эффектах от вашего имени. Он определяет, следует ли получать события ввода от USER32 или Core * или что-то еще прозрачно, в зависимости от вашей платформы, и стеки ввода могут обрабатывать перо, касание, клавиатуру, мышь и т. Д. Унифицированным образом. В нем есть встроенные средства для выполнения всех видов глобализации, доступности, взаимодействия с вводом и т. Д., Которые облегчают вашу жизнь. Но вы можете выбрать: перейти непосредственно к низкому уровню и справиться с этим самостоятельно или пропустить обработку того, что вас не волнует.

Хитрость в том, что GDI32 и USER32 были разработаны для ограниченного мира с ограниченным набором команд. Настольные ПК были единственной вещью, которая существовала: однопользовательская клавиатура и мышь, простой вывод графики на монитор VGA. Так что использовать их непосредственно на «низком уровне», как это делает conhost, довольно просто. Новые платформы можно использовать на «низком уровне», но они на порядки сложнее, потому что теперь они учитывают все, что произошло с персональными компьютерами за 20+ лет, например, различные форм-факторы, несколько активных пользователей, несколько графических адаптеров, и так далее, и дальше, и дальше, и дальше. Поэтому вы, как правило, пользуетесь фреймворком при использовании нового материала, чтобы у вас не взорвалась голова. Они справляются с этим за вас, но справляются с большим, чем когда-либо прежде, поэтому в какой-то степени они медленнее.

Значит, GDI32 и USER32 «ниже», чем новый материал? Вроде, как бы, что-то вроде.
Сможете ли вы добиться такого низкого уровня с новыми вещами? В основном да, но вы, вероятно, не должны и не хотите.
Новое живет поверх старого или старое заменяется новым? Иногда и / или частично.
По сути ... это как ответ на любой программный продукт ... «это явная катастрофа, и если бы мы все отступили на мгновение, мы бы удивились, что это вообще работает». :П

В любом случае, на одно утро хватит прогулок. Надеюсь, это несколько ответило на ваши вопросы и дало вам немного больше понимания.

Надеюсь, это несколько ответило на ваши вопросы и дало вам немного больше понимания.

@miniksa , это действительно так! Это тоже имеет смысл. Большое спасибо за то, что нашли время, чтобы все это написать! : +1:

Я пока закрываю этот выпуск. Спасибо за запрос, и я рад, что вам понравилась информация.

Была ли эта страница полезной?
0 / 5 - 0 рейтинги