Синхронизация с монитором/видеокартой при выводе изображения под Виндой Опции

[Dr.Alex]

Если тупо выводить 25 кадров в секунду по таймеру (или по мере поступления этих кадров из источника), то возникает известный артефакт (небольшой, но всё-таки).
Если момент отрисовки виндой нового кадра придётся на момент, когда видеокарта решит выплюнуть очередной кадр на монитор, то получится что часть кадра моего видео будет содержать прошлый кадр, а часть новый. При быстрых движениях в сюжете это бывает заметно.
Можно ли как-то синхронизироваться?
Конечно, если через директшоу работать, то там всё это решено, ну а если сам выводишь?

[jcxz]

Если тупо выводить 25 кадров в секунду по таймеру (или по мере поступления этих кадров из источника), то возникает известный артефакт (небольшой, но всё-таки).

Это не зависит от частоты обновления картинки.

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

Не так давно занимался выводом быстроменяющейся картинки под виндой (осциллограмма).
Обычным WinAPI (пробовал и DirectDraw - разницы в скорости - никакой).
Указанного артефакта не наблюдал. Видимо современные видеокарты (в том числе и встроенные как у меня), по дефолту уже делают двойную буферизацию
(копируют весь отображаемый экран из области хранения в область формирования сигнала в момент когда сигнал не формируется (кадровый импульс)).

Есть конечно артефакт связанный с наложением частот кадровой развёртки и обновления экрана.
Например: если картинка в каждом новом кадре смещается на один пиксел, и частота обновления картинки близка к частоте кадров, типа: 60.1 Hz и 60 Hz.
Тогда картинка будет смещаться не плавно, а дёргаться с разностной частотой. Но тут уже ничего не сделаешь. Имхо.

[Dr.Alex]

Это не зависит от частоты обновления картинки.

Этого никто и не утверждал.

Указанного артефакта не наблюдал.

Не уверен, что его можно видеть на осциллограмме. Слишком простая картинка.

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

Этого недостаточно. Видеокарта не может знать, закончила ли моя прога перерисовывать своё окно (а это только ЧАСТЬ! а не весь экран) или ещё не закончила.
Чтобы закрыть вопрос о необходимости синхронизации, вот статья Интел (с описанием именно этого артефакта).
https://software.intel.com/ru-ru/articles/v...synchronization
Жаль старая, основанная на директдро, который уже слит в отстой.
Может быть конечно в современных виндах проблема решена под корень, как тут утверждалось, но сомнительно......
Жаль пока не могу проверить под 7..

[jcxz]

Не уверен, что его можно видеть на осциллограмме. Слишком простая картинка.

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

Этого недостаточно. Видеокарта не может знать, закончила ли моя прога перерисовывать своё окно (а это только ЧАСТЬ! а не весь экран) или ещё не закончила.

Этого достаточно если рисовать правильно. Как Вам выше советовали. Т.е. - рисовать полностью видеостраницу в памяти, а затем одной BitBlt переносить из неё в видеобуфер видеокарты.
Видеокарта не может знать, а WinAPI вполне знает о Вашем вызове BitBlt и вполне может его синхронизировать с кадровой развёрткой.

Жаль старая, основанная на директдро, который уже слит в отстой.

Я уже выше писал про DirectDraw. Я пробовал его. Имхо - функции синхронизации с кадровой развёркой в DirectDraw сейчас не поддерживаются. По крайней мере мне не удалось их использовать на моей карте.
Перенос картинки через DD вполне работает, но скорость та же, что и обычной WinAPI BitBlt.