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

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

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