I’m so glad to see someone else mention this! I honestly thought I might be going crazy, thinking that inertia doesn’t feel quite right in NSScrollView. When scrolling a basic NSScrollView there seems to be a sudden jump after each flick. Scrolling does not appear smooth and is disorientating. I too have noticed this for years, and it’s always bothered me! A few months ago I tried to investigate these inconsistencies. It turns out that WebKit contains a custom reimplementation of NSScrollView which tries (and IMO succeeds) at being essentially indistinguishable from the real thing, except for the improved smoothness and faster scrolling speed, as you mentioned. I believe at least some of the hitches in AppKit you’re seeing aren’t down to rendering or view updates or anything like that, but simply because AppKit scroll event inertia is “stepped”: https://pavelfatin.com/images/scrolling-with-pleasure/scrolling-velocity.png. I think WebKit might also have a custom reimplementation of inertia (ignoring AppKit’s scroll inertia events, instead synthesizing its own), which would explain the difference. It, like every custom scroll view, also reimplements elasticity. As for responsive scrolling, I personally can’t tell the difference between NSScrollView with responsive scrolling enabled vs disabled.

[quote='816385022, DTS Engineer, /thread/770062?answerId=816385022#816385022'] That’s about it. [/quote] I have to admit that I’m mildly disappointed! I’d kind of convinced myself that workloops must be some sort of dark magic. [quote='816385022, DTS Engineer, /thread/770062?answerId=816385022#816385022'] Because the workloop is intended to be the target, not the source, of work. The idea is to have one workloop per subsystem and then have various serial queue, or serial queue hierarchies, target that. [/quote] This makes sense, thank you! I can see how workloops map well onto the ideas presented in the WWDC session you linked. Keep using serial queues where ordering matters, otherwise target everything at one workloop (instead of a serial queue) per subsystem. [quote='816385022, DTS Engineer, /thread/770062?answerId=816385022#816385022'] Honestly, if you could set a target queue I’m not sure how that’d even work. If you set a workloop’s target queue to a serial queue, you’d be back in FIFO Land™. [/quote] I was imagining that targeting a workloop at a serial queue would interleave the workloop’s work items (which are still ordered by priority) with the serial queue’s other work items (which maintain their ordering); it’s as if you’d targeted one serial queue at another, except that the first queue happens to have had its work submitted in descending priority order. Targeting a workloop at another workloop would function in the same way as how targeting a serial queue at a workloop does today, minus the ordering requirement. I suppose the purpose of this would be the same as why we target serial queues at one another: to apply labels for debugging and to assign QoS classes. Of course, none of this matters since I’m just imagining things. [quote='816385022, DTS Engineer, /thread/770062?answerId=816385022#816385022'] ps I love your blog! [/quote] Thank you for the compliment and for the fantastic answers!

I’ve filed it FB14027711.