DocumentWindow resize performance


#1

I want to raise a question that has bugged me for a while, though must admit it’s a kind of superficial.

On OSX - live-resizing an empty JUCE DocumentWindow (native or not) is slightly choppy, compared to the smoothness of, say, the main window of an empty Cocoa project, a Finder window, or other native apps like Skim or Sublime Text. By slightly choppy, I mean that the window frame appears to be redrawn roughly half as many times for a JUCE main window relative to apps that resize more smoothly. I see this behavior on 10.11 and 10.12, with or without release-build optimizations enabled, and with or without OpenGL rendering attached to the main window. Disabling CoreGraphics seems to make it worse.

Where might the overhead come from? It seems to me that ComponentPeer is a very thin wrapper around NSWindow and not likely to be the source of overhead. Has anybody looked into this?


#2

That’s not what I see on my mac… Even quite complex windows like Projucer are just as smooth as things like finder.


#3

Ok, interesting. To be clear, I also get excellent performance in resizing complex layouts, within a main window, e.g. with ResizableBorderComponent. The effect I’m seeing occurs in top-level windows (even empty ones), and it really is quite subtle. It also becomes more noticeable for larger windows, filling most of the screen. BTW, I see the same behavior in GLFW top-level windows, but raw NSWindow is perfectly smooth. Maybe my machine is just old…


#4

Yeah, I’ve sometimes seen OSX throttling the update rate for apps under some circumstances. Not sure why or when it decides to do that, but most likely this isn’t an actual problem, just a weird OS behaviour.