If it’s helpful, I’ve observed a few minor inconsistencies, although it’s unclear whether they’re related to the issue you described. According to the AppKit Release Notes for macOS 10.14, the section NSRulerView and NSTextFinder View Sizing states: For apps linked on macOS 10.14, the document of an NSScrollView can scroll under the associated horizontal and vertical NSRulerView or findBarView. This means that the NSClipView is sized and positioned under those accessories, and that will be reflected in the clip view’s contentInsets. If you’re writing a document view class that observes the containing clip view’s size to determine its own size, take these contentInsets into account when you’re determining the document size, to avoid it being larger than the inset document area. In macOS 26.1 Tahoe, the behavior doesn’t appear to be consistent with what’s described in the release notes.

After investigation, the -[NSView makeBackingLayer] method (of a layer host view) on macOS Sonoma, creates a layer of type NSViewBackingLayer, compared to the layer of type _ NSViewBackingLayer, created on macOS Ventura and earlier. Similarly, the -[NSClipView makeBackingLayer] method on macOS Sonoma creates a layer of type NSViewBackingLayer (like NSView), compared to the layer of type _NSClipViewBackingLayer, created on macOS Ventura and earlier. I think all the problems with invalidating and updating a view's rectangle arise from these changes. Last but not least, these changes interfere, inevitably and very negatively, with the responsive scrolling of the view itself. Apparently NSViewBackingLayer seems to work in a much less sophisticated way than _ NSViewBackingLayer. With macOS Ventura and earlier, tiling, clipping, responsive scrolling even with very large views at high magnification and prefetching of view content outside of its immediate visibleRect, were perfect. With macOS Sonoma, everything has gotten significantly worse. This is a serious bug. I just hope Apple fixes this immediately. ref. https://devstreaming-cdn.apple.com/videos/wwdc/2013/215xax3xz5pbbxeaxxe7z1mk3q/215/215-HD.mov

Setting NSView.clipsToBounds = YES does NOT solve the problem. Indeed, apps linked against older SDKs, have the same problem. regardless of the value of NSView.clipsToBounds, I confirm that by invalidating even just a single pt, with -[NSView setNeedsDisplayInRect:], at runloop time, dirtyRect of -[NSView drawRect: dirtyRect] is as large as the bounds of the view. In other words a catastrophe of biblical proportions, in terms of performance. These problems are easily visible with Quartz Debug.app The layer-backed NSView-derived main view (with layer.drawsAsynchronously = YES and layer.opaque = YES) of our application, for example, can easily contain thousands of vector shapes to be drawn. And with Sonoma, all drawing tools are painfully slow (compromised) because the area to be updated during drawing does not match the invalidated area during tracking. In other words, the substantial change to allow drawing outside the bounds of the View has introduced significant side effects. Even NSScrollView appears to have been completely revised, and everything that was covered in WWDC 2013 Session 215, "Optimizing Drawing and Scrolling," doesn't seem to hold true anymore. Particularly but not exclusively regarding responsive scrolling, overdraw region, etc, ... In summary, the problems are very similar to those encountered with first release of Big Sur. But those were bugs. Here, however, I fear that things are much more serious. https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-14 https://developer.apple.com/videos/play/wwdc2023/10054/?time=676