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.
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?
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!