I am calling repaint() on every mouseDrag() during a drag operation and when I move the mouse continually, there are no updates. I have to move the mouse slowly in order to see updates. It seems that the mouse drag events are taking priority over the repaints, to the extent that I never get the repaint events until I slow down with the mouse.
Did something break? Because this behavior is new.
Confirmed that adding this line after my repaint() in response to mouseDrag() solves the problem:
With this line the drag is completely smooth. This confirms that either JUCE or the operating system is prioritizing WM_MOUSEMOVE over WM_PAINT (I’m running on Windows).
That’s surprising. It’s the OS, not juce, that’s handling the order in which messages are queued and delivered, but Windows always used to be pretty good about balancing the frequency of WM_PAINT. Perhaps this is something that has changed in Windows7?
I agree this is definitely the operating system:
http://support.microsoft.com/kb/96006?wa=wsignin1.0
But is this the behavior that we want? If you look in juce_DragAndDropContainer.cpp you are compensating for this problem by calling performAnyPendingRepaintsNow (ironically, in response to my complaint from over a year ago). Unfortunately this is only useful if you’re using the drag and drop system. Any controls that dont use drag and drop but have draggable elements (like a slider), are going to suffer from this problem. Especially user defined controls that take up a large area (since you can generate a lot more mouse input).
Rather than calling performAnyPendingRepaintsNow from the drag and drop code, maybe we can call it periodically (say, every 50 milliseconds) from juce_win32_Windowing.cpp in response to WM_MOUSEMOVE while we are dragging?
Really not sure what to suggest for this one. It could even be argued that performAnyPendingRepaintsNow could be called after every mouse-drag, but obviously sometimes that would probably cause trouble too. Hmm. Don’t know!
