Мультимониторная запись без потери FPS: как не убить терминал во время раздачи

Запись экрана не должна конкурировать с терминалом за процессор именно тогда, когда каждая миллисекунда на счету.

⚠️ Почему запись экрана лагает именно в раздачу

Знакомая ситуация: весь день терминал работает идеально, но стоит начаться сильному движению — резкий импульс, каскад заявок, — как курсор начинает «прыгать», стакан обновляется с задержкой, а клик по кнопке срабатывает на полсекунды позже, чем нужно. Именно в этот момент цена решает исход сделки.

Причина обычно не в терминале, а в фоновой записи экрана. Софтовый кодек (например, x264 в OBS в режиме CPU) кодирует видеопоток силами тех же вычислительных ядер процессора, которые обслуживают интерфейс терминала. В спокойном рынке нагрузка на отрисовку интерфейса минимальна, и конкуренции за ресурсы не заметно. Но в момент раздачи терминал начинает перерисовывать стакан и ленту принтов многократно в секунду — и упирается в те же самые ядра, что и кодировщик видео.

🖥 Аппаратное кодирование против программного

У современных видеокарт есть отдельный, физически изолированный блок, предназначенный исключительно для кодирования видео: NVENC у Nvidia, AMD AMF (VCE) у AMD, Quick Sync у Intel. Эти блоки не используют основные вычислительные ядра процессора и не конкурируют с терминалом за ресурсы.

• Программный кодек (x264, CPU): лучшее качество на бит, но полностью занимает ядра процессора — риск просадки FPS растёт с числом записываемых мониторов.
• Аппаратный кодек (NVENC / AMF): кодирование происходит на отдельном чипе видеокарты, процессор практически не задействован, запись 3-4 мониторов не влияет на скорость отклика терминала.

🛠 Настройки, которые реально решают проблему

Если лаги уже случались, обычно достаточно проверить несколько параметров записи:

• Кодировщик: убедиться, что выбран именно аппаратный энкодер (NVENC/AMF), а не программный x264 «по умолчанию».
• Битрейт и режим CBR/VBR: слишком высокий постоянный битрейт увеличивает нагрузку на запись на диск — для разбора сделок достаточно среднего качества, детали стакана всё равно читаются.
• Диск для записи: запись на медленный HDD во время нескольких потоков видео создаёт свою просадку — для мультимониторной записи предпочтителен NVMe SSD.
• Фоновые процессы: браузер с десятками вкладок или параллельный майнинг видеопамяти конкурируют за тот же GPU-блок, что и энкодер.

💡 Как это реализовано в Journal Scalp Studio

Программа использует аппаратное ускорение видеокарты (NVENC у Nvidia, AMD AMF у AMD) для записи всех мониторов, поэтому терминал CScalp не теряет отклик даже в момент сильной волатильности и раздач.

Дополнительно снижает нагрузку сам принцип записи: вместо непрерывной фиксации экрана в течение всей сессии Journal Scalp Studio запускает запись по триггеру открытия позиции из локальных файлов терминала — процессор и диск не заняты постоянной записью «на всякий случай», а работают только тогда, когда действительно идёт сделка.