Seenkao писал(а):Но меня будет больше тогда интересовать работа с таймерами, особенно когда их не один и не два. Есть информация где всё посмотреть?
Вот здесь, очевидно:
https://docs.microsoft.com/en-us/window ... msg/timers (но у этих таймеров точность такая же, как у Sleep).
MysticCoder писал(а):А все эти таймеры и MsgWaitFor все равно у вас сведутся к тому, что будет вертеться отдельный поток, который будет сравнивать текущее время и будить если что главный поток, но при этом грузить проц на 100.
Ты меня вообще не понимаешь.
Первый пост делает буквально вот это:
while true do begin PeekMessageW(...); Sleep(1); end;.
Я уже несколько раз объяснил, что это переспрашивание плохо (и как раз является велосипедом, в котором ты меня обвиняешь) и специально для этого сценария предназначена функция
GetMessageW, которая не возвращается, пока не получит сообщение.
FPS выше частоты обновления экрана
не имеет смысла, кроме как узнать, сколько производительности у тебя в запасе.
FPS, равный частоте обновления экрана, обеспечивается не Sleep, а включением VSync. Этот как раз проявление того, что ожидание конкретного, не привязанного явно ко времени события имеет лучшую гранулярность: скажем, для 144 Гц-экрана оно, если отрисовка укладывается меньше чем в 1/144 секунды, выдаст 144 FPS (очень точно прождёт от 0 до 7 мс — Sleep так не умеет). Конкретный способ VSync зависит от подсистемы: по-видимому, для Vista+ Direct3D (возможно, и GDI?) это
DwmFlush.
Вот для FPS, меньшего частоты обновления экрана (как раз когда «fps не важен»), можно и поспать заданное время. Но делать это желательно через таймеры (WM_TIMER), т. к. Sleep вешает поток и т. о. мешает обработке остальных оконных сообщений.
MsgWaitFor — это именно способ подождать какого-то своего события из главного потока (изнутри цикла с GetMessage), НЕ МЕШАЯ обработке сообщений (в отличие от Sleep):
MsgWaitFor(event, timeout) возвращается либо когда событие event происходит,
либо когда приходит оконное сообщение, либо когда проходит таймаут с точностью до кванта (и различает эти случаи). Не надо было вообще про него говорить, чтобы ты не прицепился; пока у нас только окно и его сообщения, в том числе, возможно, от таймеров (WM_TIMER), он не нужен.
Крутиться в 100% загрузке только ради того, чтобы на рассматриваемом 144 Гц-экране выдать, скажем, ровно 120 FPS (вместо 50–60, которые дадут таймеры по умолчанию, или больше — 80–100 – при timerBeginPeriod(1)), нет
АБСОЛЮТНО, потому что банально отсутствие ограничения FPS даст (сюрприз) ту же 100% загрузку. Ограничение ради ограничения? Ума не приложу, почему ты вообще рассматриваешь этот вариант.