Василий Банников

Не надо путать задержку и пропускную способность.

RTT - это задержка, измеряется в секундах (милли, микро)
То что измеряется в битах (байтах) в секунду - это пропускная способность.

Если очень грубыми сантехническими аналогиями, то задержка определяется длинной трубы, а пропускная способность - её шириной.

В сетях и на то и на другое влияет очень много факторов:
1. Количество узлов между отправителем и получателем. Больше узлов - больше задержка
2. Производительность этих узлов. Чем ниже производительность - тем выше минимальная задержка и меньше пропускная способность.
3. Нагрузка на каналы связи. При высокой нагрузке будет расти задержка, так как данные будут вставать в очередь (а может и не будут вставать в очередь - они вполне могут просто отбрасываться и тогда будет тот самый packet loss)
4. То, как эти узлы обрабатывают данные, которые через них проходят. Меньше всяких проверок - меньше задержка.
5. Физическая среда и физическая длина кабелей. Чем длиннее физический путь и чем хуже среда, тем выше задержка.
Скорость распространения сигнала в оптике, меди, и по беспроводу отличается.

Как будет влиять замедление от провайдера - сильно зависит от выбранной стратегии.
Может увеличится rtt, а может будет packet loss.

Или сам момент рисования записан на видео?

Если посмотреть внимательно на то, как появляются новые линии - записан именно сам процесс рисования (ускоренный).
В некоторые моменты линии стираются и вместо них рисуются другие.

Так что кроме чисто техники тут ещё и навык нужен)

Реализуется оно достаточно просто - берёшь любую программу, в которой тебе удобно рисовать и дублируешь viewport с фиксированным зумом.
Этот отдельный вьюпорт записываешь на видео.
В это же время ты на основном вьюпорте рисуешь (можно даже поверх уже существующей картинки)

Например у тебя в patch запросе может быть какой-нибудь jsonpatch в котором будет операция "добавить элемент в список".

И вот у тебя при многократном вызове будет добавляться много элементов.

Метод PATCH не является идемпотентным по RFC 9110 => такое поведение не будет считаться ошибочной реализацией протокола.

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

Выбирай, что тебе будет удобнее.
Unity или Godot тоже вполне успешно с такой задачей справятся

Банкоматы лучше в отдельную категорию вынести, так как там много своей специфики (начиная с кассет с деньгами, заканчивая клавиатурой для пин кодов).
Новые банкоматы имеют внутри почти обычный комп на линуксе (или самый мифический "промышленный").
Чуть более старые или импортные - обычно с виндой идут.

Вендинговые автоматы тоже разные бывают - где-то вообще никакого компа нет, а кое-где видел винду+1С.

Сомнения тут лишь в надежности (работа 24/7/365????) и совместимости с нужными устройствами (терминал эквайера, принтер чеков, камера, сканер QR и т.д.)

1. Они и не работают 24/7/365
2. с камерой точно никаких проблем с совместимостью не будет. Хоть usb, хоть со специальным интерфейсом.
3 . Практически все сканеры умеют работать в режиме клавиатуры => никаких проблем с совместимостью априори не будет.

Остается чековый принтер и терминал - тут уже нужно выбирать вендора. Практически все терминалы и принтеры работают через COM-порт и имеют не очень то и сложный протокол, так что даже если нет ПО под Линукс из коробки - его не трудно разработать с нуля.

В Екатеринбурге есть достаточно большая сеть автоматов с фильтрованной водой - так там они все внутри малинку имеют. К ней подключен терминал, монетоприемник, и маленький экранчик чтобы литры с рублями показывать.

В природе встречаются все три варианта.

Вопреки соседним ответам - малинка это вполне себе промышленное решение. Не обязательно брать обычную плату и вешать лапшу из проводов - можно сделать свою специализированную плату и вставить в неё CM.

Кстати вот статья про кассы пятёрочки:
https://habr.com/ru/companies/X5Tech/articles/477738/

Это и есть нативный способ.
Microsoft.VisualBasic.FileIO - это не "прослойка visual basic", а вполне обычная библиотека. Она не более "не нативная" чем стандартная mscorlib или любая другая.

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

Альтернативный вариант - использовать функцию из winapi SHFileOperationA

Бери любой с xinput - это сейчас основной стандарт на пк.
Точно проблем не будет, если возьмёшь от xbox.
F310 и его беспроводной брат F710 тоже хороши и проверены временем, их даже на подводных лодках используют))

Если тебе только проверить, что игра видит геймпад, то можно обойтись виртуальным геймпадом. (Но для полноценного тестирования лучше всё равно взять настоящий)

Потом ещё пригодится.

Брать то что ты нашёл я бы не стал, так как он не поддерживает xinput нативно, потому он подключается только через левые драйверы, которые эмулируют Xbox геймпад => может быть много проблем

Массив - это тоже значение

Bar уже инициализирован.
Просто через Add можно вставить все элементы