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
Topic:
UI Frameworks
SubTopic:
AppKit
Tags: