Repaint throttling breaks TreeView?

I recently updated JUCE from 4.2.4 to 4.3.1 and now my TreeViews are not updating as they used to. There are two scenarios that have come to my attention: calling TreeViewItem::setOpen (true) and TreeView::restoreOpennessState on application start up. In both cases, a folder is open but its contents are not painted. It usually takes many lengthy child items for the issue to present. Clicking in the component triggers a paint to occur and ‘fixes’ the problem. The only workaround I have found so far is to post a repaint and hope for the best.

I reverted juce_mac_NSViewComponentPeer to the 4.2.4 version and the behavior vanished.

The repaint throttling should only happen in plug-in editors. Is your TreeView in a plug-in?

No, my TreeView is not in a plug in, it is in a stand alone application. Also, no windows are in live resizing.

The AsyncUpdater version of NSViewComponentPeer works, but the Timer version does not. It looks like the timer is never set in NSViewComponentPeer::repaint.

If I force drawing in NSViewComponentPeer::setNeedsDisplaRectangles with [view setNeedsDisplay:YES] then rendering is as expected, but that defeats the purpose of dirty/invalid region.

If I set the timer for 1 millisecond rather than calling setNeedsDisplayRecrangles at the end of repaint, then rendering is as expected. In the successful scenarios, the calls to NSView are done asynchronously - both triggerAsyncUpdate and startTimer (1) change the context of the call.

So, I agree. The issue is not the throttling, but the context of the call to NSView's setNeedsDisplayInRect (at least in my TreeView).

This issue has resurfaced for me when updating JUCE again. Using the timer to change the context of the call corrects the issue.