A better fix for this issue may be available in PR #915

I think we're going with the other fix, but I've linked this to the original issue for reference in case problems come up later.

I guess the purpose of this commit now is not to fix #720 but rather if we wanted to try to make the behavior of the Timer abstraction more similar across platforms.

I can buy that. You think I should merge both then?

I think it deserves a little more investigation. I'd like to try measuring the timer latency on Windows now with the Invalidate fix. Maybe compare it to Linux. It may be a non-issue now that the Invalidate calls are removed from the mouseMoved handling.

Let's leave this open for now. Removing the invalidate does fix the original problem and I want to look at this carefully on a PC...

A bit off-topic but I thought I'd throw it in here anyways.

I have also been looking at the timers, and I think there is some optimisation we can do when dragging around assemblies, it looks like it is calling GenerateAll for every mouse event, I think we should throttle these events if possible to avoid high CPU usage.

I can finally use the Profiler now from Xcode and investigating speed issues is my next area of focus.

The generateAllTimer is fascinating to me. It sets a timeout of zero. It seems to be trying to defer the regeneration to "as soon as possible after the message currently being processed." I think this ends up behaving differently on different platforms. On Windows timer messages are lowest priority so I noticed a problem of them not being called often enough it seems.

I can also see how it's possible that generateAllTimer might be firing too much (depending on the platform abstraction) maybe even more than once per screen refresh. This would mean generating frames no one sees. I think an attempt is actually made to prevent that though.

I thought I needed to throttle mouse messages for issue #720 but it turned out an unnecessary invalidate call was the root cause. Throttling the mouse messages did solve the problem by allowing the message loop, timers and painting to keep up though and improved responsiveness. I'd be interesting in what you find.

I have also been looking at the timers, and I think there is some optimisation we can do when dragging around assemblies

I would hold off on that. AFAICT dragging assemblies can be very solver intensive. A linked part only has 6 DoF but there may be hundreds or even thousands of equations in the solver depending on the number of entities. We really need to try the evil-sprirt solver patches including eigen before worrying about event handling - I think.

Interestingly, my WIP #968 currently adds a wm_timer to handle polling the USB HID of a spacemouse, since the open source library doesn't rely on window messages to transmit the data. Didn't realize this was out here.

@rpavlik This PR was an early attempt to gain some clarity on the behavior of the generateAllTimer and the showTWTimer in SS. Refreshing the text window depends on a generateAll happening first otherwise the text window will display stale data. Timers don't guarantee this ordering. #927 is an attempt to actually correct this and guarantee the ordering.

It sounds like #968 will be a very welcome improvement!