Друкувати із задоволенням

У цій статті я досліджую людські і машинні аспекти затримки при друкуванні (введення з клавіатури або «запізнювання введення») і уявляю експериментальні дані по затримці при роботі з популярними редакторами тексту та коду.

Віднедавна Затримка стала гарячою темою в комп'ютерному світі — зараз є клавіатури з малою затримкою, монітори на 144 Гц, спеціальні технології, що зменшують час затримки (як, наприклад, FreeSync або G-Sync), цікавляться цим співтовариства та інше, та інше. Звичайно, частина цієї моди створена маркетингом, але правда в тому, що мала затримка стала можливою і бажаною.

Очевидно, що геймери — перші, хто виграє від таких поліпшень. У деяких областях, таких як віртуальна реальність, затримка виявляється вирішальним фактором, навіть коли мова йде про одну миллисекунде. Але що сказати про програмістів? Потрібно нам «друкувати із задоволенням», щоб «розробляти з задоволенням»? Давайте розберемося.

Зміст:

1. Сторона людини
1.1. Зворотний зв'язок
1.2. Моторний навик
1.3. Внутрішня модель
1.4. Мультісенсорная інтеграція
1.5. Ефекти
2. Сторона машини
2.1. Вхідні затримка
2.2. Затримка обробки
2.3. Вихідна затримка
2.4. Повна затримка
3. Порівняльні тести редакторів
3.1. Налаштування
3.2. Методологія
3.3. Windows
3.4. Linux
3.5. VirtualBox
4. Висновки
5. Посилання

1. Сторона людини
Затримкою при введенні з клавіатури називається інтервал часу між натисканням клавіші та відповідним оновленням екрану. Звучить просто, але не помиляйтеся: її вплив на процес введення з клавіатури є досить складним, оскільки таке друкування є дивним проявом узгоджених дій нашого тіла і нервової системи (принаймні, з технічної точки зору).

Почнемо з основ — чи варто, взагалі, турбуватися про затримку? Адже У нас немає якоїсь поспіху, ми можемо просто друкувати, що потрібно, а результат перевірити пізніше. Кілька секунд нічого не вирішують, так адже? Не зовсім.

1.1. Зворотній зв'язок
Людина не «просто друкує», що бажає; нам потрібна зворотний зв'язок, щоб виконувати цю задачу, оскільки наші почуття утворюють т. зв. замкнутий контур управління з нашими рухами. Зоровий образ — не тільки результат введення; він є невід'ємною частиною процесу.

Чим більш повну зворотну зв'язок ми маємо при роботі з клавіатурою (друкування), тим краще. В принципі, можна друкувати з закритими очима. Ми можемо продовжувати друкувати, навіть якщо заткнемо уші, покладаючись тільки на тактильні відчуття від пальців. Однак, якщо ми заблокуємо цей останній канал зворотного зв'язку, то введення з клавіатури стане неможливим. Оскільки зоровий вид відчуття є домінуючим (інформація від інших органів чуття зазвичай підлаштовується під зір) і являє собою єдиний спосіб отримання достовірних даних про помилки введення, то зорова зворотний зв'язок має велике значення.

Зменшення затримки веде до «укорочення» петлі зворотного зв'язку, завдяки чому enter йде легше, з більшою швидкістю і точністю. Поки непогано, але де розумна межа? Зрештою, людина реагує неймовірно повільно — «шлях туди і назад» від почуттів до свідомості і потім назад до м'язів займає близько 200 мс! Безсумнівно, реакцію можна тренувати, і вона різна в людей, але деяка порівняно маленька затримка, як, наприклад, 100 мс, начебто, хороший варіант, чи не так? Анітрохи.

1.2. Моторний навик
Згадайте ваші перші спроби використовувати комп'ютерну клавіатуру. Швидше за все, вам потрібні хвилини, щоб натиснути відповідну клавішу і потім перевірити результат на екрані; цей процес вимагав всієї вашої зосередженості. Однак пролетіли місяці і роки, тепер ви вводите на клавіатурі приголомшливо швидко і напівавтоматично — ви вже не думаєте про якихось специфічних клавішах і, можливо, вже, взагалі, не дивіться на клавіатуру («сліпа друк»). Практика позначається. Такий процес називається «придбання моторних навичок» (або засвоєння рухового навику (моторне навчання)). Коли вміння досягає автономної фази, завдання може бути виконане автоматично без залучення будь-якої уваги на її виконання.

Формально кажучи, друкування (enter на клавіатурі) — це процес управління рухом, здійснюваним моторної системою людини. Оскільки друкування (enter на клавіатурі) є дрібною моторикою (відбуваються скоординовані рухи дрібних м'язів), воно сильно залежить від зворотного зв'язку. Однак ця зворотній зв'язок обробляється на рівні підсвідомості, тому ми обов'язково будемо усвідомлювати затримку, відчуваючи в той же час її серйозне негативний вплив. Час реакції людини має значення тільки для виправлення помилок.

Але навіть напівавтоматичні процеси обмежені зорової затримкою (pdf-файл), і будь-яка зворотній зв'язок хороша, тільки якщо ми можемо використовувати її. Системи зору людини потрібно близько 40 мс, щоб обробити enter. Це значення також залежить від багатьох факторів, від конкретної людини і може бути покращено тренуванням. Робимо висновок: затримка менше 20 мс була б прийнятною, так? Не зовсім.

1.3. Внутрішня модель
Перш за все, уточнимо, що будь-яка «зовнішня» затримка додається до зорової затримці, а не накладається на неї, тобто будь-яка затримка має значення. Але можна аргументувати, що значення близько 20 мс, все одно, порівняно мало. Добре, але моторна система людини знає кілька вправних трюків, щоб реагувати швидше.

Щоб протидіяти вхідним затримок у сенсорних органах і нервовій системі, система управління рухом людини використовує спеціальний нервовий процес, відомий як внутрішня модель. Цей процес може імітувати відгук (реакцію) керованої системи ще до отримання сигналів зворотного зв'язку — використання випереджаючого моделювання процесу. Додаткова інверсна модель призначена для прогнозування реакції (реакції) керованої системи на базі поточної зворотного зв'язку.

Затримка не впливає на контур зворотного зв'язку безпосередньо, вона впливає, скоріше, на внутрішню модель процесу друкування. Пряма і інверсна моделі використовуються в комбінації з деякими контурами внутрішнього зворотного зв'язку, утворюючи нелінійну систему. В результаті навіть малі затримки в сигналах зворотного зв'язку можуть призвести до значних порушень при введенні на клавіатурі (друкування).

Окремо від внутрішньої моделі існує інший процес, на який несприятливо впливає зорова затримка, — мультісенсорная інтеграція.

1.4. Мультісенсорная інтеграція
Зоровий образ є не єдиним видом зворотного зв'язку при друкуванні на клавіатурі: ми можемо чути звуки при натисненні на клавіші, відчувати тиск на наші пальці, сприймати положення рук і пальців (т. зв. проприоцепция).

Кожне з цих відчуттів обробляється окремо, і нервова система визначає, використовувати чи ні ті чи інші групи сигналів. Ця задача відома як проблема зв'язування та вже сама по собі є викликом (див., наприклад, мультисенсорні ілюзії). Коли мозок отримує впливу від більшості органів чуттів відразу, а зображення надходить з додатковою затримкою, то це ускладнює ситуацію ще більше.

Нервова система може в деякій мірі адаптуватися (pdf-файл) до постійної затримки зорової зворотного зв'язку (хоча й не ідеально), але будь-які нерегулярності тривалості затримки (т. зв. тремтіння (джиттер)) створюють додаткові проблеми через властивої їм непередбачуваності.

Є кілька показових прикладів з інших областей, де затримка сигналів зворотного зв'язку може викликати гірші наслідки, ніж її повна відсутність, аж до ситуації, коли вихідна діяльність стає взагалі неможливою: якщо грати на MIDI-клавіатурі через комп'ютер, то затримки звуку на 20-30 мс достатньо, щоб порушити ваші дії (одна стаття (pdf-файл) стверджує, що має значення затримка звуку навіть прим. на 1 мс); іншим хорошим прикладом є т. н. SpeechJammer (pdf) («винищувач балаканини»), який використовує затримку звуку зворотного зв'язку на прим. 200 мс, тимчасово порушуючи здатність людини говорити.

1.5. Ефекти
Зберемо разом ключові моменти:

• Друкування (enter на клавіатурі) є складним напівавтоматичним процесом, що вимагає роки на освоєння.
• В принципі на процес друкування можна впливати мілісекундними затримками в зоровій зворотного зв'язку.
• Зовсім необов'язково сприймати свідомістю наявність затримки, щоб, тим не менш, вона негативно впливала на вас.
• Люди сильно розрізняються по чутливості та толерантності до затримки.

Але як конкретно затримка впливає на процес друкування (введення на клавіатурі)? Тут є кілька можливих ефектів:

• Друкування сповільнюється.
• Кількість помилок і їх правок зростає.
• Очі втомлюються більше (оскільки система зору перевантажена).
• М'язи втомлюються сильніше (оскільки управління рухами стає менш визначеним).
• Процес вимагає більш усвідомленого уваги.

Точне вплив затримки залежить від багатьох факторів, таких як конкретний розподіл затримки, що використовується апаратне забезпечення (клавіатура, монітор), зміст редактора (текст або код), основний вид діяльності (вставка/редагування), метод друкування (звичайний/сліпа друк), специфіка вашого зору і вашої моторики, персональні уподобання і т. п.

Само собою зрозуміло, можливий вплив затримки навряд чи приємно. Гарна новина полягає в тому, що це працює в обох напрямках, тобто, зменшуючи зорову затримку, ми можемо, в загальному випадку, поліпшити багато аспектів (тут мова йде не тільки про швидкість друкування самої по собі)

Отримані результати, як правило, узгоджуються з наявними даними досліджень. Якщо є бажання ознайомитися з цим предметом глибше, то можна побачити деякі книги і наукові статті, які містять дані про вплив затримки і про роль зорової зворотного зв'язку на процес друкування, наприклад:

Когнітивні аспекти професійної машинопису
Роль зорової зворотного зв'язку з екрану і рук у професійній машинопису (pdf-файл)

Зокрема, варто процитувати наступне (источник):

Затримка зорової зворотного зв'язку на дисплеї комп'ютера має важливе вплив на поведінку оператора і на його задоволеність роботою.
Давайте тепер розглянемо бік машини, щоб з'ясувати, як ми можемо поліпшити ситуацію з затримкою.

2. Сторона машини
Що відбувається між моментом натискання на клавішу і моментом появи символу на екрані? Виявляється, дуже багато різного, і все вимагає часу. Можна просто купити топовий комп'ютер, щоб забезпечити собі спокійне друкування? Це допоможе, але лише певною мірою, оскільки багато частині цього процесу не залежать від центрального та/або графічного процесорів. Прийми обидві таблетки, і я покажу тобі, як глибоко йде кроляча нора (бо навіть те, що буде, є лише частиною всієї правди).

Затримка друкування може бути розділена на наступні компоненти:

• Вхідні затримка (клавіатура)
• Затримка обробки (програмне забезпечення)
• Вихідна затримка (монітор)

Розглянемо уважніше кожну компоненту.

2.1. Вхідна затримка
Спочатку розберемося, як звичайна неігрова USB-клавіатура обробляє наш enter. Такі клавіатури використовуються найбільш широко зараз як на настільних комп'ютерах, так і на лептопах.

Сканування клавіатури

Звичайна клавіатура містить більше 100 клавіш, що досить багато. Щоб мінімізувати кількість проводів і входів керуючого процесора, клавішні перемикачі зазвичай з'єднані матричною схемою, тобто «рядка» і «стовпці» проводів, що перетинаються. Завдяки цьому кількість проводів і входів можна зменшити з «x * y» до «x + y» (наприклад, з 121 до 22). Наслідком такого підходу є те, що керуючий процесор не може зчитувати стан всіх клавіш одночасно — він повинен періодично сканировать їх з постійною частотою, що веде до деякої затримки. Типова частота сканування матриці становить 1 000 Гц, тому максимальна затримка, пов'язана зі скануванням, дорівнює 1 мс (середня — 0,5 мс).

Брязкіт контактів

Незалежно від типу клавіатури клавішні перемикачі механічно недосконалі і схильні дребезгу контактів — замість «чистого» спрацьовування перемикач швидко переходить із стану «вкл.» в стан «викл.» і назад кілька разів, перш ніж зупиниться. Тривалість брязкоту залежить від технології перемикання; наприклад, для пристроїв Cherry MX, як заявлено, вона становить менше 5 мс. Хоча точний розподіл ймовірності невідомо, але базуючись на відповідних емпіричних даних, можна прийняти тривалість брязкоту близько 1,5 мс.

Усунення брязкоту контактів

Оскільки частота опитування досить велика і з-за цього брязкіт може бути інтерпретований як кілька натискань клавіші, процесор керування клавіатурою виконує т. н. усунення брязкоту контактів, усереднюючи сигнали на інтервалі часу, достатній для отримання надійного результату. Така фільтрація вводить додаткову затримку, залежну від прошивки мікроконтролера. Оскільки виробники, в загальному випадку, не повідомляють характеристики їх мікропрограм, то розглянемо типовий алгоритм усунення брязкоту і приймемо, що фільтрація додає прим. 7 мс затримки; т. о. максимальне «час усунення брязкоту» становить прим. 12 мс, а середнє прим. 8,5 мс.

USB-опитування

Оскільки USB є шиною, керованої головним комп'ютером, то клавіатура повинна чекати запит від цього комп'ютера, щоб послати дані про зареєстроване натисканні клавіші (процесор керування клавіатурою має зібрані події у вихідному буфері). Хоча USB-пристрої запитують необхідну частоту опитування при ініціалізації (до 1 000 Гц), операційні системи зазвичай використовують 125 Гц, як низько-, так і для повношвидкісних (USB1.x) пристроїв; тому максимальна затримка, пов'язана з опитуванням, становить 8 мс (середня — 4 мс). Слід пам'ятати, що часто можна збільшити частоту опитування вручну.

USB-перетворення

Деякий час потрібно також на перетворення даних. Як низько-, так і для повношвидкісних пристроїв найменша тривалість перетворення складає 1 мс. У високошвидкісних пристроїв (USB2) це час багато менше — прим. 0,001 мс (до речі, є прекрасна стаття про придатність USB для систем реального часу (pdf-файл)). Щоб мінімізувати час перетворення даних, не рекомендується підключати широкосмугові USB-пристрої (такі як, наприклад, накопичувачі, звукові карти, веб-камери) до того ж USB-контролера / хабу, до якого приєднана ваша клавіатура.

Отже, зберемо значення затримки для типової клавіатури:


Ці результати, загалом, відповідають деяким експериментальним результатам по вимірюванню запізнювання, що викликається клавіатурою.

Можна зробити краще? Звичайно, простіше простого! Використовуйте професійну клавіатуру:

• перемикачі з малим часом брязкоту (деякі навіть оптические)
• висока частота сканування матриці
• адаптивний алгоритм усунення брязкоту
• настроюється пз
• USB2 для швидкого опитування та малої затримки перетворення

Все це може значно зменшити як максимальний, так і середнє значення затримки клавіатури. Наприклад, коли я придбав клавіатуру Kinesis Advantage, я відразу відчув відміну від моєї попередньої звичайної клавіатури.

Ігрові клавіатури йдуть навіть далі — якщо ви прихильник безкомпромісного рішення, то варто розглянути щось на зразок технології Cherry's RealKey, при якій зчитування клавіш йде через аналогові входи (а не цифрові); затримка виходить майже нульова.

2.2. Затримка обробки
Затримкою обробки називається затримка між отриманням вхідного сигналу з клавіатури і генерацією зображення введеного символу у відеокадрі. Простіше кажучи, це затримка всередині самого комп'ютера.

Слід пам'ятати, що затримка обробки визначається не тільки продуктивністю — теоретично можна мати систему, яка видає 300 FPS, із «запізненням» 5 секунд після введення. Зокрема, пакетування і буферизація часто є спробою досягти більш високих робочих характеристик за рахунок затримки.

У той час як концептуально є багато різних джерел затримки обробки, на практиці вони настільки тісно пов'язані з застосуванням редактора, що всі частини зазвичай вимірюють одночасно (експериментальні дані див. у наступному розділі).

Операційна система

Після того як USB-хост («USB-порт комп'ютера) отримує дані з клавіатури, він ініціює апаратне переривання так, щоб програмний драйвер в операційній системі міг прочитати отримані дані через інтерфейс хост-контроллера (зазвичай через PCI або PCIe). Потім ці дані обробляє підсистема людино-машинного інтерфейсу (HID) в ОС, що в підсумку призводить до приміщення події «клавіша натиснута» (типу WM_KEYDOWN) чергу повідомлень операційної системи. Після цього подія відправляється циклом подій у вікно активного додатку.

Всі ці дії вимагають деякого часу, але воно дуже мало для нашої мети (друкування на клавіатурі). Що тут важливо, так це те, що основні операційні системи (а саме — Windows, Mac і ОС на базі Linux) не є системами реального часу, тому гарантія на значення затримки відсутня. Як апаратні процеси (мережевий введення/виведення, введення/висновок збереження тощо), так і багатозадачність програмного забезпечення можуть збільшити час обробки непередбачувано (і необмежено).

До речі, оскільки програми графічного інтерфейсу можуть накладати певні обмеження на системну затримку, було багато успішних спроб оптимізувати планування ядра Linux спеціально для випадку «настільного» використання (зокрема, через систему динамічної оптимізації «ulatencyd»).

Для простоти припустимо, що наш комп'ютер не має значної завантаження при введенні з клавіатури; тоді затримки такого роду будуть менше 1 мс.

Віртуальна машина

Якщо текстовий редактор / IDE працює поверх віртуальної машини процесу (JVM у Java або CLR.NET Framework), то додаткові затримки можуть виникнути тому, що їх середовище виконання також не є системою реального часу (за винятком спеціальних реалізацій, як, наприклад, Real time Java).

Продуктивність сама по собі звичайно не створює проблеми, але, коли включається JIT-компілятор або складальник сміття, можна очікувати деяке «запізнювання». Движки JavaScript і інтерпретатор Emacs Lisp також породжують такий тип затримок.

Основні віртуальні машини значно вдосконалилися за багато років, тим не менш, певний попередній «прогрев» міг би бути, все ж, корисним, щоб гарантувати стабільну затримку.

Редактор

Ця частина — найбільш значуща. Використовується редактор може дати основний внесок у затримку друкування. На відміну від затримок, створюваних апаратурою, максимальна затримка в редакторі практично не обмежена (можна легко натрапити на 1-2 секунди).

Оскільки редактор зав'язаний в основному на центральний процесор, можна зменшити затримку редактора, застосовуючи більш потужну машину (допомагає також хороший графічний процесор). Але надія тільки на потужність не зовсім виправдана — вона часто йде не туди, де вона, дійсно, потрібно найбільше (наприклад, коли ви запускаєте сервер розробки або обробку даних у фоновому режимі). Також майте на увазі, що навіть першокласний ноутбук може бути набагато більш млявим енергозберігаючому режимі (на акумуляторі), тому такий підхід ефективний тільки частково. Крім того, він досить дорогий, як відомо.

Є шлях краще — в принципі нам не потрібен суперкомп'ютер для спокійного друкування — все, що ми повинні зробити, так це реалізувати використання редактора, пам'ятаючи про поставленої мети. Друкування в редакторі є порівняно простим процесом, тому навіть комп'ютери на 286 процесорі забезпечували досить швидкий enter. Цілком можливо досягти близьку до нуля затримку друкування навіть у складному сучасному IDE, що є саме тим, на що націлений режим друкування з нульовою затримкою в IntelliJ IDEA. Технічні подробиці див. у моїй статті про візуалізації з малою затримкою в AWT і Swing (незважаючи на те, що розглядається платформа Java, ключові ідеї можуть бути поширені на більшість сучасних операційних систем і фреймворків для побудови графічних інтерфейсів користувача).

Редактори/IDE сильно розрізняються по затримці друкування. Наступна глава містить велику кількість емпіричної інформації по темі.

Конвеєр візуалізації

Центральний і графічний процесор працюють паралельно і взаємодіють через буфер команд, доповнений буфером відеодрайвера. Більшість команд візуалізації є асинхронними. Тому вони мають повне право не запускатися відразу, як тільки відпрацює метод відтворення. Команди малювання накопичуються в буфері відеодрайвера, потім пакетируются і направляються в буфер команд графічного процесора (робиться спроба отримати більш високу частоту кадрів за рахунок затримки). Результуюча затримка, залежно від комбінації апаратного забезпечення / операційної системи / програмного інтерфейсу програми / відеодрайвера — може змінюватися від незначної до вельми істотною.

Типове додаток настільного комп'ютера працює поверх фреймворків для побудови графічних користувацьких інтерфейсів, тому воно ізольовано від знаходиться нижче конвеєра візуалізації і, таким чином, від синхронізації візуалізації (візуалізації). Зазвичай це прийнятно, оскільки багато програм для настільних систем нечутливі до затримки. Однак деякі дії надзвичайно чутливі до неї (як, наприклад, друкування в IDE), із-за чого редактори можуть явним чином «проштовхнути» команди в буфері і примусово отрендерить кадр, щоб зменшити затримку. Як приклад, див. роботу синхронізації в OpenGL. Також можна подивитися демонстраційний матеріал про «проштовхуванні» конвеєра.

Подвійна буферизація

Щоб не показувати частково промальований кадр і представити зображення на екрані відразу цілком, багато додатків звертаються до т. зв. подвійної буферизації — зображення спочатку готується під внеэкранном «вторинному буфері, а коли всі графічні операції завершені, оновлена область зображення передається в кадровий буфер чи побітового копіювання або перемикання сторінки. Багато фреймворки (наприклад, Swing) виконують подвійну буферизацію за замовчуванням.

Зайве говорити, що цей додатковий крок призводить до додаткової затримки. документації Java сказано: «Якщо вашої показником продуктивності є просто швидкість, з якою відбувається подвійна буферизація або перемикання сторінок порівняно з прямим рендерінгом, то ви можете бути розчаровані. Може виявитися, що значення прямого візуалізації будуть набагато перевершувати такі у подвійної буферизації, а ці, в свою чергу, будуть багато вище ніж у перемикання сторінок.»

Іноді подвійна буферизація абсолютно необхідна, в інших випадках це фактично не вимагається; тому редактори повинні використовувати подвійну буферизацію обачно, щоб не допустити надмірного зорової затримки. Подальшу інформацію див. у демонстраційному матеріалі на витратам буферизації.

Менеджер вікон

Сучасні програми рідко працюють в повноекранному режимі; більшість середовищ робочого столу показує кожну програму в окремому вікні. Цю задачу виконують т. н. менеджери вікон, які можуть бути розділені на кілька класів у залежності від того, як відбувається промальовування і оновлення вікон.

стекові віконні менеджери організують зображення вікон так, що спочатку виконується промальовування вікон, розташованих позаду. У той час як у цього підходу є деякі недоліки (необхідність явного відновлення вмісту вікна), він не вносить додаткові затримки, тому що додатки малюють безпосередньо в кадровому буфері. Приклади стекових віконних менеджерів: Classic theme в Windows, Openbox в Linux.

Композитні менеджери вікон використовують замість кадрового буфера виділений внеэкранный буфер для кожного вікна і потім виводять на екран всі вікна разом, коли (і як) вони вважають за доцільне. Цей поділ неминуче призводить до деякого збільшення затримки. Приклади компонующих менеджерів: Aero Windows Compiz в Linux.

Відповідні емпіричні дані наведені в наступному розділі.

Вертикальна синхронізація

Вертикальна синхронізація або V-Sync є методом запобігання розриву зображення на екрані, тобто такого стану, коли дисплей показує інформацію з декількох кадрів в одному зображенні екрану. Виникають спотворення найбільш помітні на горизонтально рухаються об'єкти з різкими вертикальними краями (тобто не під час друкування).

V-Sync зводиться до очікування нового кадру у створеному відеосигналі перед передачею вмісту вторинного буфера в кадровий буфер (таким чином, V-Sync передбачає подвійну буферизацію). Тому при включеній вертикальної синхронізації може бути додаткова затримка перед оновленням кадрового буфера. Максимальна затримка становить приблизно 17 мс, середня — близько 8 мс (для частоти оновлення 60 Гц). Цікаво, що ця затримка пов'язана з оновленням екрану, з-за чого її середнє повне значення зростає лише приблизно на 4 мс, оскільки частина цієї затримки є непереборний (залежить від вертикальної позиції символу). Максимальне збільшення повної затримки досягає, все ж, приблизно 17 мс.

Середовища робочого столу зазвичай не дозволяють явно вибирати, включати чи ні V-Sync. V-Sync у Windows дозволена в Aero, але заборонена в Classic theme. V-Sync у Linux, здається, вимкнена, як в композитних, так і в стекових віконних менеджерах.

В деякому сенсі V-Sync змушує графічний процесор адаптуватися, щоб контролювати частоту оновлення, що є спадщиною ери електронно-променевих трубок. В даний час є набагато кращі рішення (див. нижче).

Розглянемо значення затримки для типового комп'ютера (приймаємо, що значні навантаження на ввід/вивід і обчислювач відсутні і що використовується стековий менеджер вікон без V-Sync):


Ці затримки набагато менш передбачувані, ніж затримки, спричинені апаратними засобами, і вони дуже чутливі до конфігурації комп'ютера. В принципі повна затримка обробки може бути як 0-1 мс, так і 10 с. Ось чому теоретичних роздумів тут недостатньо і потрібні деякі точні цифри див. у наступному розділі великі емпіричні дані.

Як можна покращити ситуацію з затримкою обробки? Тут є кілька шляхів:

• Редактор/IDE з малою затримкою
• Потужне апаратне забезпечення комп'ютера (центральний і графічний процесори)
• Стековий менеджер вікон (Classic Windows theme, Openbox тощо).
• Відсутність вертикальної синхронізації

Очевидно, що редактор має найбільше значення.

2.3. Вихідна затримка
Розглянемо, як типовий неігровий рідкокристалічний монітор показує згенерованого зображення.

Оновлення екрану

Зображення екрану комп'ютера зберігається в кадровому буфері в пам'яті відеокарти (або поділюваної відеопам'яті). Монітор не має прямого доступу до кадрового буфера; замість цього відеоконтролер генерує відеосигнал, що передається через відеоінтерфейс (такий як VGA, DVI, HDMI, DisplayPort і т. д.), завдяки чому монітор може безперервно оновлювати свій внутрішній буфер зображення. Ця передача відбувається з фіксованою частотою, званої частотою оновлення, яка для звичайних ЖК-моніторів дорівнює 60 Гц. Тому можна очікувати, що максимальна затримка, пов'язана з оновленням, дорівнює приблизно 17 мс, а середня — біля 8 мс (оскільки нам потрібно показати тільки новий введений символ, то можна не враховувати час, необхідний для передачі повного кадру).

Запізнювання дисплея

На відміну від ЕПТ-монітора, який повинен показати вхідне зображення негайно (тому що його єдина «пам'ять» — післясвічення люмінофора), РК-монітор має свій власний буфер для зберігання зображення. В принципі це робить можливим затримати показ вхідного зображення, щоб змінити розміри, виконати деінтерлейсінг, або «поліпшити» його (або просто отримати повний кадр, перш ніж оновити пікселі). Виникає затримка відома як запізнювання дисплея (або «запізнювання введення монітора»). Це явище отримало широкого розголосу останнім часом, але воно все ще є досить спірною темою. Вимірювання запізнювання дисплея часто є неправильними, оскільки важко відокремити це зміщення від часу відгуку пікселя (див. прекрасний звіт Prad по запізнюванню введення, щоб зрозуміти, як робити це правильно). Хоча в гіршому випадку затримка може бути 2-3 кадру (тобто до 50 мс при частоті оновлення 60 Гц), запізнювання введення представлено, в основному, в телебаченні високої чіткості, а не в моніторах комп'ютерів; тому можна прийняти, що ця затримка близька до нуля для типових моніторів. Тим не менш, хорошою ідеєю буде вимкнути все «коректори зображення на вашому моніторі (як не дивно, і овердрайв теж).

Відгук пікселя

Пікселі РК-дисплея не можуть реагувати на зміни керуючого напруги негайно. Інтервал часу, необхідний для зміни пікселя на дисплеї, називається часом відгуку пікселя. Цей час залежить, в основному, від технології РК-матриці TN, IPS, VA тощо). РК-монітори пройшли довгий шлях, знижуючи час відгуку пікселя, і сучасні TN-монітори (використовуються найбільш широко в даний час) мають середній час відгуку всього лише близько 4 мс.

Отже, зберемо значення затримки для типового комп'ютерного монітора:


Чи можна зменшити вихідну затримку? Тут є кілька надійних методів:

• Ігровий монітор, що забезпечує мале запізнювання дисплея і більш швидкий відгук пікселя.
• Монітор з частотою оновлення 144 Гц (затримка, пов'язана з оновленням, дорівнює 3,5 мс).
• Комбінація відеокарти і монітора, яка підтримує Adaptive-Sync FreeSync або G-Sync з динамічною частотою оновлення (до 240 Гц) і синхронні оновлення.

Всі ці заходи можуть знизити повну вихідну затримку до прим. 1-2 мс.

2.4. Повна затримка
Узагальнимо , середні затримки у всіх компонентах затримки друкування:


Типовий комплект складається із звичайної неігровий клавіатури і звичайного РК-монітора. Ідеальна конфігурація припускає клавіатуру і монітор (ігровий), мають малу затримку.

Вхідна і вихідна компоненти затримки строго визначаються періодичними апаратними процесами, які можуть бути оцінені з високою точністю. Ці затримки не залежать від продуктивності центрального і графічного процесорів і мають передбачувані верхні межі. Типова середня затримка клавіатури і монітора разом становить близько 26 мс, що саме по собі трохи, але якщо її додати до затримки обробки, то затримка редактора буде більш помітною. Навіть затримка введення/виводу сама по собі вже перевищує поріг людського сприйняття.

Затримка обробки на відміну від затримок введення/виводу визначається, в першу чергу, обчисленнями центрального і графічного процесорів, тому вона залежить від апаратного забезпечення і має практично необмежену максимальне значення. Неможливо передбачити затримку обробки; потрібно виконати належні порівняльні тести, щоб отримати ці дані. Теоретично ідеальна затримка обробки може бути близька до 0-1 мс.

У той час як кожна частина розглянутої ланцюжка має значення, редактор є найбільш слабкою ланкою, що вносять основний внесок у затримку друкування.

3. Порівняльні тести редакторів
Щоб експериментувати з вимірюванням затримки обробки, я підготував «Typometer» — інструмент для визначення та аналізу зорової затримки текстових редакторів (джерела).

Typometer генерує вхідні події ОС і робить знімок зображення екрана, щоб виміряти затримку між натисканням клавіші та відповідним оновленням екрану. Таким чином, вимір охоплює всі складові затримки обробки (тобто чергу ОС, віртуальна машина, потік графічного процесора, буферизація, менеджер вікна і можлива вертикальна синхронізація). Такий підхід є правильним, тому що всі компоненти, по суті, переплетені з редактором і, в принципі, редактор впливає на них.

3.1. Конфігурація
Тут описана конфігурація апаратного і програмного забезпечення, що використана для тестування:

Апаратне забезпечення:

• ПРОЦЕСОР: Intel Core i5 3427U, 1,8/2,8 ГГц, кеш 3Мб
• Графіка: Intel HD 4000 (драйвер v10.18.10.3958)
• Пам'ять: 4 Гб DDR3
• Дисплей: 1920 x 1080, 32 біта, 59,94 Гц

Програмне забезпечення:

Microsoft Windows 7 HP x64 SP1 6.1.7601
Lubuntu Linux 15.10 Desktop amd64
VirtualBox 5.0.10 на Windows (установки за замовчуванням, повноекранний режим)

Редактори:

Atom 1.1
Eclipse 4.5.1
Emacs 24.5.1
Gedit 3.10.4
GVim 7.4.712
IntelliJ Idea CE 15.0
Netbeans 8.1
Sublime Text 3083

Зверніть увагу, що, оскільки порівняльні тести виконуються на одних і тих же апаратних платформах і на одній і тій же версії кожного редактора, то результати можна прямо порівнювати. Результати можуть змінюватися залежно від конфігурації, тому для порівняльного тестування був використаний досить типовий комплект (не дуже повільний, але і не дуже потужний); це робить результати є більш репрезентативними.

Були обрані лише ті редактори, які забезпечують, як мінімум, підсвічування синтаксису. Безсумнівно, Notepad (Блокнот) — самий швидко реагує редактор, але було б просто несправедливо порівнювати його з будь-яким практично корисним редактором.

Додатково були виключені випадки роботи редактора в терміналі, оскільки термінал може істотно впливати на затримку друкування. До речі, сучасні ОС більше не підтримують справжній текстовий режимконсоль Windows і віртуальна консоль Linux (через Alt+Fn) моделюються поверх графічного кадрового буфера.

Аналіз був виконаний в R. Графіки були представлені за допомогою ggplot2.

3.2. Методологія
Всі редактори/IDE працювали з налаштуваннями за замовчуванням, вікна додатків були максимизированы.

Редактор працював або з порожнім текстовим файлом, або з XML-файлом (точніше, з Maven-схемою). XML був обраний тому, що він підсвічується у всіх редакторах і не залежить від інших файлів проекту.

Typometer використовував наступні параметри:

• Кількість символів: 200
• Затримка: 150 мс
• Доступ: нативний
• Режим: синхронний

Затримка 150 мс була обрана тому, що вона являє собою середній часовий інтервал між натисканнями клавіш при моєму власному досить швидкому друкуванні (мінімальний інтервал дорівнює 40 мс). Точне значення не відіграє великої ролі, оскільки Typometer в синхронному режимі чекає, коли з'явиться символ, перш ніж зробити паузу і надрукувати наступний.

Був використаний класичний віконний менеджер Windows, оскільки, як було сказано вище, композітінг, здійснюваний у Aero, збільшує затримку рендеринга і примусово включає вертикальну синхронізацію (тести показали, що Aero тема, справді, робить усі редактори менш сприйнятливими). Тут дано порівняння тестів GVim (один з найшвидших редакторів взагалі) в Classic theme і Aero (пунктирні лінії на 16,68 і 33,37 мс):

Вплив Windows Aero на затримку промальовування (GVim)


Можна бачити, що Aero вносить, як мінімум, одну кадрову затримку (прим. 16,7 мс для частоти оновлення 60 Гц) і веде до дискретизації по часу. Це приховує внутрішню продуктивність редактора і спотворює процес порівняльного тестування. Як я зазначав раніше, затримки відеосигналу, створювані вертикальною синхронізацією, трохи менше затримок у кадровому буфері, але середня різниця становить лише 4 мс, а максимальна, яку затримка дорівнює, все ж, 17 мс (для 60 Гц). Оскільки ефект досить суттєвий, люди часто виявляють додану затримку «неозброєним оком» в тестах на час реакції людини.

Графік демонструє, що Typometer має дуже хорошу точність вимірювання затримки — нижні значення знаходяться так близько до теоретичного 16,68335, що це виглядає майже як результат математичного розрахунку.

Як для Linux, перевагу було віддано Lubuntu замість Ubuntu з тієї ж причини — Compiz дає додаткову затримку в промальовування програми. Тут представлений графік (з медіа лініями):

Вплив Linux Compiz на затримку промальовування (GVim)


Середня внесена затримка становить прим. 8 мс, що краще значення у Aero; тут також відсутня дискретизація, що викликається синхронізацією (але тут спостерігається зростання джиттера). Оскільки V-Sync не використовується, то затримки відеосигналу знаходяться на рівні затримок у кадровому буфері. Краще використовувати стековий менеджер вікон (типу Openbox), щоб отримати більш високу точність вимірювання.

Враховуючи, що виміряні затримки найшвидших програм, таких як Notepad, нижче 1 мс стабільні, здається виправданим припустити, що вимірювальний інструмент забезпечує достатню точність і відтворюваність. Оскільки зв'язок між кадровим буфером і вихідним відеосигналом детермінована, результати можна розглядати як репрезентативні.

Незважаючи на багате розмаїття спостережуваних залежностей, можна виділити наступні типові часові ряди:

Типові часові ряди затримки редактора


Прості редактори демонструють дуже стабільні значення затримки, хоча середня величина може бути порівняно великий.

Складні редактори (і редактори, що працюють поверх віртуальної машини / інтерпретатора) на додаток до більш високої середньої затримки часто мають тенденцію до більш високої мінливості затримки (джиттер).

Поширене також проміжне поведінка, коли інтервали стабільного значення затримки періодично перериваються випадковими викидами. Іноді затримка проявляє тенденцію, що показує лінійну залежність від алгоритмів редактора з горизонтального позиціонування символів.

3.3. Windows
Як введення в методику аналізу затримки, рекомендую переглянути велике обговорення, як не треба виміряти затримку, яке пояснює, чому середні значення краще медіанних в якості запобіжного затримки і чому максимальні значення дуже важливі.

Текстовий файл

Подивимося підсумкову таблицю (відсортовано за середнім значенням затримки). SD означає тут середньоквадратичне відхилення, що використовується як міра джиттера. Врахуйте, що тут представлена «ідеальна» ситуація — простий порожній файл без виділення. Будь-яка інша конфігурація показала б більш високі затримки за визначенням.

Затримка редактора Windows (текстовий файл):


Підсумкова таблиця дає нам змогу лише приблизно оцінити розподіл затримки, тому корисно доповнити її відповідної більш детальної графікою. Традиційні гістограми не дуже зручні для порівняння декількох наборів даних. Діаграми розмаху («ящики з вусами») є занадто грубими. Скрипкові діаграми краще, але вони виглядають досить дивно для людей, які не займаються професійно статистикою.

Є більш зручний спосіб, який також і виглядає краще, — можна графічно зобразити значення на горизонтальній осі з деяким доданим випадковим вертикальним зсувом, щоб показати розподіл (є додаткова інформація про такому підході). Результуюча діаграма є простий і описової і дозволяє порівнювати різні набори даних:

Затримка редактора Windows (текстовий файл)


Очевидно, редактори не створені рівними (принаймні, за затримку).

По-перше, середня затримка значно розрізняється — більш прості редактори мають тенденцію до більш низької затримки. Переможцем є GVim, але і IDEA з включеним режимом нульовою затримки знаходиться дуже близько до GVim. Всі редактори на базі JVM (у т. ч. IDEA в режимі за замовчуванням) знаходяться внизу, що цілком передбачувано, поступаючись тільки Atom, т. к. робота Chrome виявилася ще більш млявою.

Іншою помітною відмінністю є джиттер — «легкі» редактори демонструють дуже стабільну затримку, тоді як складні, навпаки, мають набагато більш широкий розкид значень. IDEA в режимі за замовчуванням показує найбільший розкид затримки з високим максимальним значенням.

Гістограма показує докладний вплив режиму нульової затримки в IntelliJ IDEA:

Вплив режиму нульової затримки в Windows (текстовий файл)


Режим нульової затримки позначається позитивно, знижуючи середню затримку та усуваючи джиттер (але не повністю).

XML-файл

Ясно, що попередній набір є занадто «штучним»; зрештою, для редагування порожнього файлу без підсвічування синтаксису можна взяти просто Notepad. Для чогось більш серйозного використовують інший редактор. Виконаємо введення в порівняно великому файлі XML, щоб побачити, як зміняться значення:

Вплив типу змісту на затримку редактора (Windows)


Ух ти! Відмінність досить помітне і водночас незвичайна. Деякі редактори — GVim і IDEA в режимі нульовою затримки — ну, просто, «круті хлопці», їм «по барабану». Однак у більшості редакторів затримка рівномірно зросла. Середня затримка в IDEA злегка зменшилася (що дивно), але максимальна — збільшилася. Найбільш сильне зміна відбулася у Emacs, затримка якого просто злетіла в небо.

Енергозбереження

Тепер отсоединимся від мережі електроживлення і будемо працювати від акумуляторів в режимі енергозбереження.

Затримка редактора Windows (XML-файл, енергозбереження):


Розглянемо докладніше, як це вплинуло на затримки:

Вплив режиму енергозбереження на затримку редактора (Windows, XML-файл)


На більшості редакторів це помітно не позначилося, але є пара цікавих винятків: IDEA і Netbeans. У IDEA максимальна затримка злетіла до 240 мс, що, цілком очевидно, що вище порога «ощутимости».

Тут показано, як режим нульової затримки позначається в даних умовах:

Вплив режиму нульової затримки в Windows (XML-файл, енергозбереження)


І знову, хоча він не усуває джиттер повністю, значний вплив.

3.4. Linux
Продовжимо наші спостереження в Linux, пропустивши для простоти синтетичний тест з порожнім файлом.

Затримка редактора в Linux (XML-файл):


Додаткова діаграма з докладним розподілом затримки:

Затримка редактора в Linux (XML-файл)


Порівняння з попередніми результатами в Windows:

Вплив ОС на затримку редактора (XML-файл)


Загальною особливістю є те, що джиттер в Linux помітно вище для більшості редакторів (за винятком режиму нульової затримки в IDEA, де джиттер фактично зменшився).

Emacs і Atom виграють в Linux — їх середня затримка тут помітно менше.

У GVim, Sublime Text, Eclipse та IDEA (режим за замовчуванням), навпаки, затримка в Linux набагато зросла. Найбільш сильний вплив зазнала IDEA — максимальна затримка досягла 200 мс навіть в режимі звичайного харчування. Час реакції Eclipse також сильно постраждало.

Друкування в IDEA в режимі нульовою затримки є, звичайно, переможцем (тут IDEA обійшов навіть GVim).

Вплив режиму нульової затримки в Linux (XML-файл)


Режим нульової затримки в Linux демонструє низьку і виключно стабільну затримку.

3.5. VirtualBox
Тепер припустимо, наприклад, що ми використовуємо Windows, насамперед, для ігор, а працюємо на віртуальній машині Linux (дійсно, чому б і ні?). Як зміняться затримки редактора в такій ситуації використання? Подивимося.

Затримка редактора в Linux (VirtualBox, XML-файл):


Тут дано порівняння з попередніми «природними» результатами:

Вплив віртуалізації на затримку редактора (Linux, XML-файл)


Крім дискретизації затримки (що викликається або вертикальною синхронізацією, або іншим видом дискретної синхронізації буфера) ми можемо бачити постійне зростання затримки для всіх редакторів. Розподілу сильно не змінюються, що легко пояснити (базові алгоритми зберігаються при візуалізації). Максимальна затримка в IDEA зросла до 350 мс.

Енергозбереження

Щоб отримати повну картину, переключаємося на акумулятори. Режим енергозбереження разом з VirtualBox є, ймовірно, найбільш напруженою комбінацією для затримки редактора.

Затримка редактора в Linux (VirtualBox, XML-файл, енергозбереження):


Н-да, такі затримки просто безглузді! Максимальна затримка тепер перевищує півсекунди!!!

Для наочності порівняємо ці дані з результатами при ідеальних умовах:

Вплив конфігурації на затримку редактора


Цілком очевидно, що конфігурація відіграє важливу роль в результуючій затримці редактора. Проте редактори реагують по різному — робота деяких може бути серйозно погіршена, тоді як на інших це позначається несильно.

Найкращу стійкість продемонстрував IntelliJ IDEA з включеним режимом нульовою затримки. Подивимося, як це виглядає в найбільш складній ситуації:

Вплив режиму нульової затримки в VirtualBox (Linux, XML-файл, енергозбереження)


Цікаво, що в режимі нульовою затримки IntelliJ IDEA перевершує всі інші редактори (і, до речі, консольні редактори теж).

4. Висновки
Звичайно, те, ви друкуєте, набагато важливіше того, ви друкуєте. Однак зорова зворотній зв'язок з малою затримкою часто може зробити цей процес більш ефективним і більш приємним.

• Використовуйте швидко реагує редактор.
• Використовуйте клавіатуру з малою затримкою.
• Вимкніть всі «поліпшувачі зображення на вашому моніторі.
• Увімкніть стековий менеджер вікон у вашій ОС.

Друкуйте з задоволенням!

5. Посилання
Дивіться також:

Typometer — інструмент для вимірювання та аналізу зорової затримки в редакторах тексту/коду.
Процес відтворення з малою затримкою в AWT і Swing — детальний аналіз джерел затримки в архітектурах AWT і Swing, методів значного зниження затримки промальовування.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.