[jakobegger]

Having just spent two days optimising the scrolling performance of my Mac app I understand the reasoning behind this. Fluid scrolling is hard. And while scrolling might be handled in part by the GPU, its still the CPU that renders the text that you're scrolling. If you're aiming for 60FPS, you probably have less than 10ms to render a screen when the user is scrolling quickly.

[blkhp19]

If you don't mind me asking, what optimizations are you making? I'm curious about what it takes to get 60 FPS scrolling in a Mac app.

[jakobegger]

In my specific case, I'm displaying a table view with hundreds of rows and potentially dozens of columns. The bottleneck was the slow text rendering in App Kit. Text rendering is pretty fast when you render long strings, but there is a lot of overhead when rendering many short strings.

My first step was to switch to using CoreText, a lower level API for rendering text. This reduced overheads by around 50%.

My second step was to cache layout information for recently displayed strings in a small cache. Tables often contain a lot of repeated values so this saved a lot of time; in some cases up to 70%.

After these optimizations, my own code was no longer the bottleneck. I still don't reach 60FPS on my 2009 Macbook Pro, but that was expected...

(Note: 60FPS scrolling is not a problem if your views are smallish, so that they can be entirely cached on the GPU; the problem occurs only when your views are very large and the users scrolls very fast so that the CPU can't keep up with rendering tiles for the GPU)

[blkhp19]

I'm not too familiar with how a table view in OS X compares to UITableView on iOS, but are cells reused? I feel that that optimization alone would at least limit what needs to be rendered to what's on screen.