aciddose wrote:Actually those are what I was referring to. Both will lead to WM_PAINT immediately. I was surprised to find this with InvalidateRect.
It seems to be working now, so my comments about it being exactly the same are invalid.
My point still stands regarding the fact you're just deferring through the OS API though. The only way to ensure you get reliable animation framerates is to be in control of redraw directly from your own thread. A plugin launching a thread for animation doesn't seem like a brilliant idea in my opinion, whatever though if it works.
What doesn't work is calling InvalidateRect from your own timer thread however, so we're back to square one.
The host must provide idle() in the GUI thread to allow you to call InvalidateRect, which then defers the update until the host calls PeekMessage.
So we still need editor->idle() to make these updates work, even if InvalidateRect works correctly. It also is still not a very practical method to implement animation because the host can't control it directly and there is no way to know exactly how long the WM_PAINT message will be deferred or exactly how the invalid rectangles will be collated.
It is easy for the host to ensure 16ms calls to editor->idle, not for WM_PAINT.