Paint method called while moving a window

I am using juce_1_31, I am facing one problem with this…

While moving the window, window’s paint method is called, which will bring down the performance…

I was using juce_1_19, and that has no issues…

Please help!!!

Thanks in advance

I guess you’re talking about the mac version? I noticed this as well recently, but it seems to be because of a change in OSX, which now appears to send repaint events every time a window is moved. It’s on my list of stuff to sort out…

I’m currently evaluating Juce and would like to know if there are news on this issue. Mac is an important target for my project and I would like to get the best possible “felt” application performance. At the moment when I’m moving around the main window of the Juce Demo Application (OSX 10.4.9 2x2.5G5 PPC) the window moves with a much slower refresh rate than all other Mac Apps I’m using. Is this because of the additional paint messages that are handled by Juce befeore OSX actually updates the window position with the display manager? If so, can I do something to prevent that from happening?

Any deeper insight into this would be of great value to me :slight_smile:



OSX used to be fine, but at some point they changed it so that windows get redrawn when they’re moved - in most mac apps this doesn’t matter because they use a closed mouse-tracking loop, which blocks the events. For the next release, I’ve added some more mac-style mouse-tracking which improves this.

(Of course if you’re using a native title bar, it drags like any other mac window).

Thanks for your quick reply Jules. I’ve tried to run the demo application with the native title bar and honestly the behaviour is still the same. The moving window seems to be updated only half as often (at most) as all other Application windows. You can easily see that effect because the moise pointer is moving seperately from the title bar when dragging the window (i.e. the window is moving slower than the pointer) for the Juce application. All other apps feel like the pointer is linked to the window. It just feels strange.

So I figure the event loop explanation would not hold. Do you agree?

To my understanding the whole rendering process should be in the hands of the display/composition manager when simply moving a window and there should not be anything that needs an update outside the GPU. Am I wrong there? Why is OSX sending paint messages when moving the window in the first place? Wouldn’t a window with content that depends on the screen position simply intercept some sort of WindowBeingDragged message and do its update work there?

I’m slightly confused,


The loop explanation definitely holds, because when I changed my code to use a mouse-tracking loop, the windows moved much more smoothly. I suspect that the OS might be cheating by handling window movements differently when the app is inside a loop like this.

I was looking at this issue anyway for other reasons, so am sure it’ll be better in the next release.

Ok, thanks a lot Jules!

I was only confused because you said that a native title bar application would behave better and it didn’t (for me).



Sorry, I just assumed a native title bar would be different - I didn’t actually try it.