Проц не грузит(не более 1 - 2% показывает диспетчер задач)
Плохо только, что дёргается немного скроллинг. Видимо используется таймер(ну, который Timer, который на форму кидается).
Он как-то кривовато работает с маленькими задержками....
Предлагаю попробовать отдельный Thread + Sleep() с подкрученным перед этим таймером для увеличения точности
https://msdn.microsoft.com/ru-ru/library/wi...8(v=vs.85).aspx


Кстати помнится у меня были проблемы когда я рисовал из другого потока. Так что рисуйте только из основного потока!
Вполне может быть, что существует не многопоточный способ убрать эту дерготню.... Это я просто предположил, что дело в таймере. Просто я когда-то наблюдал такие-же подергивания когда таймером анимировал выезд строки в титрах.

Кстати еще как-то использовал для точного измерения времени QueryPerformanceCounter(), может удастся сюда приспособиьт как-нибудь
https://msdn.microsoft.com/en-us/library/wi...8(v=vs.85).aspx

Да, наверняка дергается из за того что таймер нестабильно выдает тики.
С потоками у меня совсем труба и программирование на С++ не мой основной профиль, на асм еще куда ни шло )
Если кто напишет как запихать эту прогу в быстрый, стабильный опрос можно попробовать разогнать ее , посмотреть до каких пределов )))

Сообщение отредактировал whale_nik - Sep 3 2016, 20:33

а, ну если чисто для пробы то
в цикле while(!Application.terminated() )
{
делаете то что вы делаете сейчас в обработчике онтаймер;
потом Application.processMessages();
}
Ну там в документации гляньте, может Terminated это не функция...
В общем это наверно будет самое быстрое что можно сделать легко и просто

Цикл этот запихните в обработчик кнопки старт например.

Таймер тут не причем, просто поток, ушедший в Sleep получит управление только тогда, когда не будет активных потоков более высокого приоритета, а это может случится хоть после обеда

Ну Sleep() это я предложил просто. Хотя вы правы, в MSDN этот момент описывается.
Я тут подумал, что в принципе таймер это просто надстройка над API

http://docwiki.embarcadero.com/Libraries/B...ExtCtrls.TTimer

Есть информация, что стандартное разрешение таймера в венде 15.6ms
https://randomascii.wordpress.com/2013/07/0...gawatts-wasted/
Думаю это довольно мало для наших целей...

Так что самое первое что надо попробовать - таки задрать частоту таймера(не забыть потом вернуть как было!)
https://msdn.microsoft.com/en-us/library/wi...6(v=vs.85).aspx

Я тут начал задумываться а как вообще тогда сделать плавную анимацию средствами GDI?

Add:
Провел эксперимент: увеличил частоту таймера. Ничего не изменилось.
Заметил кстати, что изменяя ширину окна изменяется и скорость движения пикселей... Очень странно....

Таймера в винде для такого иные, см. BOOL QueryPerformanceFrequency(LARGE_INTEGER *lpFrequency);
BOOL QueryPerformanceCounter(LARGE_INTEGER *lpPerformanceCount)

По этим таймерам не получишь пробуждение потока. Только время померить можно.
Чтобы не дёргалось изображеие, копать надо в сторону синхронизации с кадровой развёрткой видеокарты.
И если хочется чтобы под виндой потоку и процессу меньше мешали другие процессы/потоки, повышайте приоритет и потока и процесса: SetThreadPriority()/SetPriorityClass().
Но опять-же - если поток уже ушёл в Sleep то получить управление он может только с дискретностью таймера виндового шедулера, который 18.2Гц всего.
Ну хотя если получит событие от периферии какой-либо, то может тоже пробудится? Например - от изохронной точки USB с частотой 1кГц может быть сможет пробуждаться.
Но винда - это не реалтайм система, она не для того делалась, так что гарантии нет никакой.

Автор, а чего в сторону Direct2D не посмотрите? Двумерная графика с аппаратным ускорением.
Я недавно его к Питону (IronPython) прикрутил.

Провел тут пару экспериментов со слипом...
за основу было взято это
https://www.daniweb.com/programming/softwar...the-windows-gdi

В общем создать в Visual Studio Win32 проект и скопипастить туда
http://pastebin.com/USiiAXxZ

fps специально зажат, чтобы цикл упирался именно в Sleep()
таким образом равномерность движения будет зависеть только от равномерности слипа.
Также интересно раскоментить //timeBeginPeriod(1); в WinMain() и убедиться, что Sleep() тоже начинает работать точнее.
Т.е. виндовый шедулер зависит от частоты таймера(о чем в MSDN тоже где-то читал).

Сам скроллинг сделано втупую на циклах... тут не в этом прикол как говорится.

Кстати у ТСа пиксели какие-то большие в примере! Вот тут у меня реально 1000*800 как в первом посте указано.

Во вложении exe для проверки плавности ) У ТСа проблема с плавностью явно не из-за проблемы точности Sleep()! Ибо там рывки такие, что со стула упасть можно

P.S. кстати если в цикле оставить только BitBlt то получается более 500FPS. так что сама операция отрисовки на экран реально быстрая!

Я писал ещё в самом начале: пробовал DirectDraw, разницы в скорости между ним и ...Blt-функциями WinAPI не увидел.
Из чего сделал вывод, что WinAPI изнутри и вызывает DirectDraw когда нужно.

Ну а мне было больше даже интересно Sleep() по тестировать. То что Blt работает реально быстро это факт.
Кстати я до сих пор не нашел ответа как сделать реально плавную анимацию и при этом не грузануть процессор?
Да, высокий приоритет потока + разгон таймера вроде дают желаемый эффект даже со Sleep(), но это не правильно.
Крутить цикл и не засыпать тоже можно - но это еще более неправильно!
Кто знает как по правильному реализовать гладкую анимацию(скроллинг)?

Так пробовал, ничего не работало, все виснет намертво почему то.


Насчет пикселей в том примере что у вас там сразу по три выводиться для скорости, это был пример для Антохи с 5 сек на экран.

Сообщение отредактировал whale_nik - Sep 4 2016, 19:17

Странно.. при условии, что в цикле есть вызов Application.processMessages(); висеть не должно...

Удалил файл проекта так как вы уже свой написали, я просмотрел )



Счас спробую .

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

вот по три точки сразу в бесконечном цикле без таймеров и задержек

Сообщение отредактировал whale_nik - Sep 4 2016, 19:18

Ну проц и должен грузиться сильно. В цикле же нет Sleep(). Т.е. процесс не отпускает процессор и делает непрерывно свою работу.

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