Программы, которые не тормозят

Лаг ввода формируется еще из разных мест. Частота опроса сенсора мыши не равно частота опроса кнопок мыши и тут может легко пойти разлад, хотя вроде бы что такое 7 миллисекунд разницы да? Вот только когда цель мечется влево-вправо это очень сильно влияет и не на быстрых мониторах, которые по-своему, но тоже влияют на общий лаг, так как чем быстрее монитор тем чаще опрос может попасть перед кадром. Вот только есть еще пара нюансов и один из них частота фактически съемки и он может быть как 150 раз в секунду, так и 750 раз в секунду, а это разница в 5 раз. И опрашивать сенсор, который фактически снимает с частотой 150 кадров с частотой выше 1000 герц просто бесполезно и ненужно. На винде то можно поднять частоту опроса составного устройства. На линуксе же вроде как только частоту опроса сенсора можно выставить до 1 миллисекунды или же 1000 герц. А клавиатура тоже лаг создает при вводе и часто там 120 герц реальная частота работы самих кнопок. Возможно поэтому так критична производительность самих программ чтобы этот лаг был поменьше. И ненужно быть киберспортсменом чтобы замечать эту разницу, ведь они тоже люди. Игры и так работают нереально быстро тратя минимум ресурсов на самом деле на саму игру. Это просто обзорщики тупые и не в курсе какой должна быть конфигурация ПК для игр чтобы снизить бесполезную нагрузку на ЦП и память чтобы отклик стал меньше. Можно конечно всякую муть обозвать как-то по-особому но в Quake Champions есть настройка или брать данные DirectX или напрямую игра это будет делать, что позднее сделали. И всякие типа технологии по сути ускоряют кривую работу через DirectX, что никак не влияет по сути на прямой ввод потому что все и так максимально реактивно. И 300 кадров что в CS2, что в Quake Champions вывозит и простая видеокарта. А замечать можно глазами и результатами. Если ты с ботами с монитором 60 герц стреляя только из одного вида оружия безостановочно в режиме Нечестивой троицы все 30 минут имеешь скажем 33% попаданий рельсы по маленькому чемпиону это не выдающийся показатель. А вот если у тебя 40% это уже довольно приличный результат, если это без увеличения на любом расстоянии. И вот тут ты можешь и не видеть конкретную работу, но результат может отличаться в большую сторону. Остальное не принципиально, ведь когда ты точно знаешь что рельса будет 50% или выше у тебя модель поведения сразу меняется с осторожной при 33% на достаточно уверенную. Можешь кстати сравнить количество своих попаданий в голову и подумать какого хрена в CS2 что ни лунь то бошкострел неписанный. Смысл один - попасть в голову. Вот включаешь режим мгновенной смерти и смотришь сколько реально у тебя попаданий в голову, а не то что валв нарисовали. С рельсы попасть то тяжело, не то что в голову - просто в чемпиона размером на 15% меньше уже тяжко попадать. Этот говеный самообман с хедшотами давно пора разоблачить посадим мамкиных хедшотеров в Quake Champions и поглядеть как они будут попадать. Там от силы несколько раз за сотню они могут попасть в реальности. Скорость кадров одинаковая может быть скажем те же 300 кадров. Я не знаю что они там подкрутили, но это аимботство ходячее, причем бошкострельное. И сразу миф про адских киберспортсменов развалится потому что большинство из них с вареными мозгами попадают как боги, если это не Quake.

впервые я столкнулся с тормозами 17 июня 2017 года

А какой тогда был монитор, уже на 270 Гц или малость поменьше?

сравнил то же самое прямо сейчас:

foot:

$ time seq 1000000
...
seq 1000000  0.24s user 0.98s system 99% cpu 1.221 total

alacritty:

$ time seq 1000000
...
seq 1000000  0.20s user 0.93s system 99% cpu 1.132 total

как видим цифры почти одинаковые, при этом foot не использует GPU и весит гораздо меньше alacritty. Статистика в арче например:

Package Size: 	304.8 KB
Installed Size:	710.6 KB

vs

Package Size: 	2.5 MB
Installed Size:	8.6 MB

Konsole

seq 1000000 0,01s user 0,40s system 96% cpu 0,423 total

Yaquake

seq 1000000 0,01s user 0,36s system 97% cpu 0,376 total

Kitty

real 0m0,281s user 0m0,003s sys 0m0,277s

Uxterm

real 0m0,412s user 0m0,007s sys 0m0,405s

LXterm

real 0m0,405s user 0m0,013s sys 0m0,295s

Alacritty

real 0m0,283s user 0m0,000s sys 0m0,283s

+

Лол, ты хотел разницу на статической картинке получить? Разница заметна должна быть, тест специально для этого разработан, прям как tearing test который можно найти на ютубе. Но учитывая что у тебя ноутбук, возможно вмешиваются другие характеристики экрана, такие как время перехода пикселя, в ноутбуки понятное дело нормальное железо не ставят.

Первая картинка должна быть лучше чем две нижние, которые будут похожи на друг друга. 120 гц это конечно тоже мало, между тремя тормозами разницу определить сложнее чем между хорошим результатом и плохим.

i3, 60 гц, 4 гб памяти. На том компьютере nedit летал, и сейчас летает. И как были заметны задержки в gtk3, так и сейчас заметны.

Все приложения tui(консольные), командные , либо имеют свою реализацию отрисовки на подобие mpv

Что конкретно я использую

Kitty

Nvim

MPV

Bluetui

Lazygit

В остальном к сожалению использую гуи основанные на qt или gtk

В большинстве терминал

Через программу Typometer протестировал некоторые редакторы и терминалы, тест заключается в вводе одного символа, а программа замеряет через сколько он появится

# Title					Min	Max	Avg	SD
XTerm + Compositing OFF			0,7	2,1	0,9	0,1
XTerm + Compositing ON			1,8	2,8	2,2	0,2
St + Compositing OFF			2,9	3,4	3,1	0,1
Xfce4-Terminal + Compositing OFF	26,3	27,9	26,9	0,3
Konsole + Compositing OFF		11,4	12,4	11,9	0,2
XNedit + Compositing OFF		0,7	1,2	0,9	0,1
Kate + Compositing OFF			1,1	2,1	1,4	0,1
gVim GTK3 + Compositing OFF		1,0	3,8	1,1	0,2
Mousepad + Compositing OFF		0,7	2,8	1,0	0,2
Vim XTerm + Compositing OFF		0,8	3,9	1,0	0,2
JB PyCharm + Compositing OFF		0,7	2,3	1,4	0,2

И для терминалов прогнал time seq 1000000

• XTerm - 2,5s
• Rxvt - 0,2s
• Konsole - 0,6s
• St - 0,4s
• Xfce4-Terminal - 0,5s

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

Выводы такие, даже программы на Java как PyCharm могут иметь хороший инпут-лаг, и то что тест на один символ явно не дает понимания тормозит ли программа с выводом.

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

// gcc video.c $(pkg-config --libs --cflags sdl2) -o video
#include <string.h>
#include <time.h>
#include <SDL.h>

int main(int argc, char **argv)
{
	SDL_Init(SDL_INIT_VIDEO | SDL_INIT_EVENTS);
	SDL_Window *window = SDL_CreateWindow("", 100, 100, 1000, 1000, SDL_WINDOW_SHOWN);
	SDL_Renderer *render = SDL_CreateRenderer(window, -1, SDL_RENDERER_ACCELERATED);
	struct timespec t = { 0, 2000000 };
	for (;;) {
		SDL_SetRenderDrawColor(render, 255, 255, 255, 255);
		SDL_RenderClear(render);
		SDL_RenderPresent(render);

		SDL_SetRenderDrawColor(render, 0, 0, 0, 255);
		SDL_RenderClear(render);
		SDL_RenderPresent(render);

		nanosleep(&t, NULL);
		SDL_Event e;
		while (SDL_PollEvent(&e)) {
			if (e.type == SDL_QUIT) return 0;
		}
	}
	return 0;
}

// gcc term.c -lcurses -o term
#include <unistd.h>
#include <string.h>
#include <time.h>
#include <ncurses/ncurses.h>
#include <sys/ioctl.h>

int main(int argc, char **argv)
{
	int h, w;
	struct winsize size;
	ioctl(0, TIOCGWINSZ, (char *) &size);
	h = size.ws_row;
	w = size.ws_col;

	char buff1[h][w];
	char buff2[h][w];

	memset(buff1, '#', sizeof(buff1));
	memset(buff2, ' ', sizeof(buff2));
	for (int i = 0; i < h; i++) {
		buff1[i][w - 1] = '\n';
	       	buff2[i][w - 1] = '\n';	
	}
	struct timespec t = { 0, 2000000 };
	for (;;) {
		clear();
		write(1, buff1, sizeof(buff1));
		clear();
		write(1, buff2, sizeof(buff2));
		nanosleep(&t, NULL);
	}
	return 0;
}

• rxvt нет мерцания
• xterm нет мерцания
• st нет мерцания
• xfce4-terminal заметное мерцание
• konsole заметное мерцание

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

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

или вообще не выбирают, пользуются тем, что есть

Все так. Пользователи вообще редко в терминал заходят. Публикую эти тесты для себя и интересующихся.

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

Да нет, я вот без проблем отличаю 60 от 120. При 120 меня укачивает и тянет блевать.

не тормозит в отличии от того же гимпа

Ага. То чувство, когда даже неродной Kolourpaint в Xfce запускается быстрее, чем родной GIMP. И чувствуется, что делалось для людей. Хотя, функционал не сравнится, конечно. Даже прозрачности под текстом нет. Но по мелочам удобнее использовать.

plan9port, хотя оно местами бажное

Имеет одну из самых эффективных реализаций grep (1).

[у меня тормозят] vim, emacs в любом виде

Ну в контексте ПК это не такие критичные тормоза. Но сеть с низкой пропускной способностью и высокими задержками сделают даже vi-over-ssh непригодным.