Intercepting WM_PAINT

I’m using SDL 1.2.14, along with Direct3D for rendering. In D3D-based apps, it’s typical to render in response to WM_PAINT messages, e.g.:

Code:
case WM_PAINT:
// D3D rendering goes here…
ValidateRect(hwnd, NULL);
return 0;

In windowed mode, this ensures that the window will continue to render correctly when (e.g.) it’s being moved around the screen.

In order to facilitate this, I’ve hooked into the SDL window proc, like this:

Code:
WNDPROC SDLWindowProc;

LRESULT CALLBACK CustomWindowProc(
HWND hwnd, UINT msg, WPARAM wparam, LPARAM lparam)
{
if (msg == WM_PAINT) {
// Do D3D rendering here…
ValidateRect(hwnd, NULL);
return 0;
} else {
return CallWindowProc(SDLWindowProc, hwnd, msg, wparam, lparam);
}
}

void HookWindowProc()
{
SDLWindowProc = (WNDPROC)SetWindowLongPtr(
GetActiveWindow(), GWLP_WNDPROC, (LONG_PTR)&CustomWindowProc);
}

This seems to work fine. However, it does mean that SDL’s own code for handling WM_PAINT events doesn’t get executed. Is this a problem? Does that code need to be executed even when using Direct3D, or is it ok to skip it?

I think this should really be a part of the main SDL code, and not your own code.
But if you insist on doing it like this… you can always hook system events using SDL’s API, check for the WM_PAINT event type, and then call SDL_RenderUpdate only upon receipt of the event. This should fix all renderers in the same manner.------------------------
EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

Jesse A. wrote:

No, but this is something that would be a benefit to all users of SDL under all renderers

Sure, I agree with that. I was under the impression that the SDL 1.2.14 code was pretty much locked though. In any case, it seems unlikely that a new feature of this sort would be adopted at this point.

Doesn’t mean this is necessarily done in SDL 1.3, though. It would be beneficial there, too.

Jesse A. wrote:

you can always hook system events using SDL’s API, check for the WM_PAINT event type, and then call SDL_RenderUpdate only upon receipt of the event.

If so, this is the part I’m not clear on. What do you mean by ‘hook system events’? Are you talking about modifying the SDL source code? Hooking into the window proc? Or just listening for SDL_SYSWMEVENT events via the usual methods?

The last one.------------------------
EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

[quote=“Nathaniel J Fries”]
Jesse A. wrote:

No, but this is something Or just listening for SDL_SYSWMEVENT events via the usual methods?

The last one.

As I mentioned earlier, WM_PAINT messages are not forwarded as system events. (Again, this can be confirmed by looking at the source code or printing out all SDL events that are received.)

If I’m wrong about this, let me know. But, I’ve checked it pretty thoroughly, and I’m pretty that what you’re suggesting isn’t possible (hence the window proc workaround).