Our MacOS application has a single window which is occupied by an NSView-derived view. It's been working for the last ten years or so, but when using the Sonoma beta, window updates are badly broken.
We rely on using setNeedsDisplayInRect to redisplay any portions of the view that need to be redisplayed, but no matter how small a rectangle we specify, the entire window is repainted with the background colour before our drawRect implementation is called. We already provide an overload of isOpaque in our view which returns true, and in the past this was effective for suppressing the background fill, but it no longer seems to work (although I can confirm that it is still called along the way).
I've attached an image that shows an example of how a sample window looks after resizing (which is correct) and then what it looks like after using setNeedsDisplayInRect to invalidate the region occupied by the button in the centre. I've explicitly set the NSWindow background colour to blue to make it more obvious :
Is it still possible to inhibit the background fill? Repainting the entire view for every update is not really an option for us, for performance reasons
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