I think this happens because the Windows GetMessage() function blocks while the window is being moved. It might be possible to work around this in Panda’s C++ message loop, but I’ve never looked into it.
If you find a way to make a work, we’ll be happy to incorporate your patch.
Some googling suggests that this problem has been encountered before by a lot of people, specially in the context of game programming.
The main problem here is with DefWindowProc (and not GetMessage). Once the user clicks on the title bar of the window and the generated WM_SYSCOMMAND(SC_MOVE) message is sent to DefWindowProc for default processing, the procedure blocks until the user leaves the hold on the window (apparently it runs its own loop). http://www.panda3d.org/dox/cxx/html/win_graphics_window_8cxx_source.html#l01864
Given the Panda mechanism, as I understand it, this is not a solution for us since we are doing lots of rendering stuff followed by one call to process_event on each window per frame. Hence there is no single do_render() function to call from the timer.
The only non-hacky solution I can think of is a little radical: do window event processing in a different thread. Is that feasible?
May be somone can suggest a better method in the light of the above info.