Open Radar

 
In some scenarios an NSTextView will leave temporary garbage on the screen when being resized in an NSSplitView.

In particular, and NSTextView whose scroll view and clip view are compatible with responsive scrolling will exhibit this behavior to varying degrees depending upon the type and numbers of controls installed in the other split subview.

The only workaround I have found is to either build against the 10.8 SDK or to subclass NSTextView to explicitly turn off support for responsive scrolling by overriding the +isCompatibleWithResponsiveScrolling method.

Steps to Reproduce:
1. Download and open the attached example project.
2. Build and run.
3. Follow the instructions on the screen, briefly: move the splitter left and right until you see the egregious drawing of garbage to the screen on the left, NSTextView side of the splitter.

Expected Results:
The resizing of the split views with the divider should always yield clean redrawing by each of the affected views.

Actual Results:
As the splitter is move from the left to the right, effectively growing the NSTextView on the left, "garbage" or residue from the right-side view is left where it has just been scrolled away from.

For whatever reason it exacerbates the problem to have a large number of controls on the right side view so in the example project I've included an absurdly large matrix.

This bug affects me in my real world app, MarsEdit, which has a side bar with many popup buttons that can be resized, affecting the width of the window's text view.

Currently I am working around the problem by forcing responsive scrolling off for the affected text views, but I would like to enable responsive scrolling in the future. If you can share with me a more effective workaround for compiling against the 10.9 SDK while retaining responsive scrolling and avoiding this bug, I'd love to hear about it.