While trying to debug some weird drawing issues under macOS 14, I remembered that there was a comment in the AppKit Release notes related to drawing and NSView.clipsToBounds.
Under the section titled NSView, the following statement is made:
For applications linked against the macOS 14 SDK, the default value of this property is true. Apps linked against older SDKs default to false. Some classes, like NSClipView, continue to default to true.
Is this statement possibly backwards? From what I can tell, under macOS 14 NSView.clipsToBounds now defaults to false.
I came across this while trying to debug an issue where views that override drawRect with the intent of calling NSFillRect(self.bounds) with a solid color are, sometimes, briefly flickering because self.bounds is NSZeroRect, even though self.frame is not (nor is the dirtyRect).
This seems to be happening when views are added as subviews to a parent view. The subviews, which override drawRect, periodically "miss" a repaint and thus flicker. This seems to happen when views are frequently added or removed, like what happens in a scrolling view that is "recycling" views as they go offscreen. Views that scroll into the viewport are added as subviews and, sometimes, briefly flicker.
Replacing calls to drawRect with wantsUpdateLayer and updateLayer eliminates the flickering, which makes me think something is going astray in drawRect and the various rects you can use.
This is with Xcode 15.4, linking against macOS 14.5 and running on macOS 14.6.1
Hey, thanks for bringing this to our attention. Indeed I was able to confirm that the release note contains a typo.
This is a difficult problem to diagnose using the information we have received from you so far. Please provide a bug report that includes an Xcode project and some directions for using the Xcode project that we can use to reproduce the problem. Once you have filed a new bug, please post the feedback number here.
Bug Reporting: How and Why? has tips on creating your bug report.