Achieving fluid animations in Win32 API without message pump control

Other Questions API
1

Hey folks! I’m stuck trying to get smooth animations working in a plugin I’m making for another app. My code uses OpenGL for real-time 3D stuff and I want it to run at 60 FPS if possible.

The issue is I can’t control the main message loop like I usually do. I’ve tried a few things:

  1. Using WM_TIMER - but it’s not accurate enough
  2. Calling InvalidateRect right after drawing - makes the whole app unresponsive
  3. Making a worker thread to post custom messages

Here’s a snippet of my current approach:

void WorkerThread(Plugin* plugin) {
    while (plugin->IsRunning()) {
        WaitForSingleObject(plugin->GetUpdateEvent(), 100);
        Sleep(0);
        PostMessage(plugin->GetHwnd(), WM_CUSTOM_DRAW, 0, 0);
    }
}

LRESULT CALLBACK WindowProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam) {
    switch (msg) {
        case WM_CUSTOM_DRAW:
            InvalidateRect(hwnd, NULL, FALSE);
            return TRUE;
        case WM_PAINT:
            DrawStuff(hwnd);
            SetEvent(GetPlugin(hwnd)->GetUpdateEvent());
            return TRUE;
    }
    return DefWindowProc(hwnd, msg, wParam, lParam);
}

It kinda works, but the app still misses messages sometimes. Anyone know a better way to handle this? Is there a standard approach for plugins that need frequent repaints? Thanks!

2

have u tried using timeSetEvent() from winmm.lib? it gives better resolution than WM_TIMER. you could set it to fire every 16ms (60fps) and use that to trigger ur redraws. just make sure to handle any thread safety stuff if needed. might be worth a shot!

3

Have you considered using a dedicated rendering loop with vsync? This approach can provide smoother animations without relying heavily on the Windows message loop.

Here’s a potential solution:

Create a separate thread for rendering, and use wglSwapIntervalEXT(1) to enable vsync. In the render thread, implement a while loop that calls Sleep(0) to yield CPU time and use QueryPerformanceCounter() for proper frame timing. Only invalidate the window when a redraw is necessary. This method achieves a consistent 60 FPS and works well in plugin architectures where control over the main message loop is limited.

Thread synchronization is essential, especially when managing OpenGL contexts across threads. Good luck with your plugin!

4

I’ve faced similar challenges with Win32 API animations, and I’ve found that using a high-precision timer can work wonders. Instead of relying on WM_TIMER or Sleep(), try using QueryPerformanceCounter() for more accurate timing.

Here’s a technique that’s worked well for me:

  1. Set up a timer using SetTimer() with a shorter interval (e.g., 1ms)
  2. In your WM_TIMER handler, use QueryPerformanceCounter() to check if enough time has passed for your desired frame rate
  3. If it’s time to update, post your custom message and reset the timer

This approach gives you more precise control over your frame timing without bogging down the message loop. It’s also worth considering using DirectComposition or the Desktop Window Manager (DWM) for smoother animations if your plugin’s host application supports it.

Remember to profile your code to ensure your drawing routine isn’t causing performance bottlenecks. Sometimes, optimizing the render path can make a bigger difference than tweaking the message loop.