Throttle status bar spinner animations to save CPU

[evangrayk]

This PR fixes (well, improves) #96094, where spinners in the status bar cause higher-than-desired CPU usage in the "Code - Helper (GPU)" process. It's just showing a spinner, which should require very little CPU usage. If the animation is throttled to 20FPS, the CPU usage drops by a lot while still appearing visually smooth. In my typical usage with extensions and files open, my CPU usage in the GPU process goes from ~25% to ~10%. When repro'd on a blank build of OSS VS Code, this is less dramatic (5-8% to 2-3%) but still quite nice. This helps reduce battery drain, especially if you have a lot of extensions that show spinners. Note of course that the measurements here are specific to my machine and are kind of eye-balled.

The spinner still appears quite smooth after this:

(Keep in mind this gif is capped at 25FPS, but it is still somewhat representative of how it looks)

I think it could go down to <20FPS and still look OK, with commensurate decreases in CPU usage (down to 5-8% instead of 10%).

Another option would be a "low power mode" setting for this, and allow this to go down to more like 15-18FPS for much bigger reductions in CPU. This PR just does the minimal change that maintains smoothness to be non-contentious.

How to test this change:

Add an extension which creates a status bar spinner, e.g.:

const vscode = require('vscode');
export function activate(context) {
    const statusBar = vscode.window.createStatusBarItem(vscode.StatusBarAlignment.Left);
    statusBar.text = '$(sync~spin) Test';
    statusBar.show();
    context.subscriptions.push(statusBar);
}

When this is visible, look at activity monitor / some other process list. Notice CPU% usage of "Code - OSS Helper (GPU)". If you use devtools to reset the steps CSS change to linear, notice an increase in the activity monitor %CPU (or check before and after this PR for the same workspace).

[msftclas]

All CLA requirements met.

[kassens]

Note this is 30 steps per 1.5s, so 20fps (there might be an off by 1 error in my calculation, not sure how steps work on repeat).

[evangrayk]

Good point, thanks. I still think it's a good level of visual smoothness for the performance win here, even if that means it's 20FPS instead of 30FPS.

[joaomoreno]

Very interesting approach, I like it!

Thanks! 🍻