623: It’s About Human Connection
https://atp.fm/623
Nerdy home-buying considerations, Hyperspace updates, the surprisingly difficult engineering challenge of scrolling, and how we're going to get through all of this.
🏳️🌈❤️🏳️⚧️
@atpfm @siracusa I've just been listening to your Hyperspace table view discussion whilst putting together a basic AppKit example. I've started with 100,000 items in my table and it's smooth as silk when scrolling. I haven't done macOS development in some years now so I'm pretty rusty, was surprised I couldn't repro your issue. Any chance you kept the sample app demonstrating the problem?
I'm gonna try SwiftUI next, I imagine the issue will be easy to encounter there!
@Drarok Try a web browser with the same content to see how much smoother it can be. (Grab the scroll thumb and yank it around. Don’t just swipe.)
@Drarok @atpfm @siracusa I’ve not seen scrolling issues with NSTableView. My app currently has two big NSTableViews with 6.5 and 7.9 millions rows (view-based, auto-layout within each “cell”) that are loaded on-demand from a SQLite database. They’re very smooth yanking the thumb around (on an M1 Pro). It is slightly slower than when I was using NSCell, but it sounds like you have something else going on. I’d be interested to see an Activity Monitor sample from scrolling your app…
@mjtsai @Drarok Doing the NSCell version helped me find a case in my NSView-based version where an init() chain (through several subclasses) was failing to set the identifier on view, causing new ones to be created too often. Fixing that made the NSView-based version just about as fast as the NSCell-based one, so I went back to that. (The NSView-based one was nicer in a few other ways as well.)
@siracusa Chrome blanks out when using the scroll thumb, NSTableView works perfectly fine?
@Drarok Yeah, like I said on the show, web browsers give up after a certain point. But up to that point, they're smoother.
@siracusa I get what you're saying, but I couldn't disagree more. Even when comparing Chrome with 1000 items to native with 100,000 the performance of the latter is flawless for me.
@siracusa @Drarok Not sure where the bottleneck is is in the web view, but you may consider content-visibility and contain-intrinsic-size to help with performance https://css-tricks.com/almanac/properties/c/content-visibility/
@Drarok Funny, I'm in the process of switching to old-style NSCell because it does actually seem to make a difference in performance for my data/UI.
@siracusa weird! Do you have loads of columns? Without seeing any slowdown it's hard to guess where the issue might be. Might be worth identifying the root cause rather than going for refactor number... 6?
@Drarok Too late! I dunno why NSCell-based is faster, but it is (slightly). I tried to use Instruments but I don't know how to use it well enough to tell where the time was being spent.
@Drarok Are you using NSTableCellView or are you returning NSTextViews from tableView(_:viewFor:row:)? Or something else?
@siracusa returning NSTableViewCell instances in tableView(_:viewFor:row:) which are created by tableView.makeView(withIdentifier:owner:)
I think you might be holding something wrong!
@Drarok Yeah, me too, but see my other reply for the culprit!