TL;DR: It seems to be a problem in Chromium, the relevant CSS (one second change) results in a 60hz animation cycle.
Workaround:
"editor.cursorBlinking": "solid"Workaround:
"editor.cursorBlinking": "solid"Kind of ridiculous that it's so easy to make this mistake.
Sure maybe you can get smarter and realize that all animations run at 2 hz and then also only check at 2 hz, but it seems the root problem here is an entirely different one.
This also has nothing to do with the blinking interval. A setInterval would simply not do the same. The CSS animation is fading its opacity at 60 fps not toggling it. Doing the same with a setInterval(.., 1000/60) will use the same amount of CPU.
As any introductory tutorial about css animations explains: They interpolate between the percentages you are not providing! So thats a DOM update every 12ms. The reason its smooth is because opacity (like transform) does not trigger a relayout.
Finally, whatever is triggering relayouts is not the opacity change, but some other obviously badly written code that is continously triggered on requestAnimationFrame and is touching the DOM even though, zero dom writes should be taking place on idle. (And zero dom reads always! Since reading from the DOM triggers synchronisation between the rendering thread and the js thread)
Most of the cursor styles have some sort of animation, but the "blink" style is just an on-off blink with no fade. Chrome updates every animation at 60hz, even step animations like these. This is an acknowledged issue in the Chrome bug tracker as linked in the issue.