Better performance for custom-shader-animation option

[BrunoMSantos]

Custom shaders are an interesting feature, but prohibitively wasteful for constant usage, at least in my case.

Here's radeontop on idle with and without a no-op shader on a 5700xt with ghostty in full screen, 4k (note that it's also quite spiky, but these weren't cherry picked in favour or disfavour of my point). The laptop gets it worse.

With, always @ ~120Hz:

              Graphics pipe  27.50%
───────────────────────────────────
               Event Engine   0.00%

Vertex Grouper + Tesselator  13.33%

          Texture Addresser  18.33%

              Shader Export  20.00%
Sequencer Instruction Cache  13.33%
        Shader Interpolator  23.33%

             Scan Converter  20.83%
         Primitive Assembly   0.00%

                Depth Block  20.00%
                Color Block  20.83%

         2626M / 8093M VRAM  32.44%
          170M / 15987M GTT   1.06%
 0.88G / 0.88G Memory Clock 100.00%
 0.74G / 2.10G Shader Clock  35.04%

Without, @ ~45 Hz:

              Graphics pipe   0.83%
───────────────────────────────────
               Event Engine   0.00%

Vertex Grouper + Tesselator   0.00%

          Texture Addresser   0.00%

              Shader Export   0.00%
Sequencer Instruction Cache   0.00%
        Shader Interpolator   0.00%

             Scan Converter   0.00%
         Primitive Assembly   0.00%

                Depth Block   0.00%
                Color Block   0.00%

         2637M / 8093M VRAM  32.58%
          228M / 15987M GTT   1.42%
 0.88G / 0.88G Memory Clock 100.00%
 0.01G / 2.10G Shader Clock   0.69%

The shader used for testing:

void mainImage(out vec4 fragColor, in vec2 fragCoord)
{
	fragColor = texture(iChannel0, fragCoord.xy / iResolution.xy);
}

A part of this is that ghostty will never drop below ~120Hz when the shader is enabled on my system, though it drops to the minimum ~44-48Hz with it disabled. I do get why, though I'm not sure why it doesn't just peg it at maximum when running the shader (144Hz in my case). Beside the point I suppose?

Not sure what the better approach would be to improve on this, but I was thinking of 2 things:

1. An option to set custom-shader-animation somewhere between true and false, as a cool down period. E.g.:

   custom-shader-animation = 0.5 # seconds

2. Possibly a way to configure triggers could be interesting too. I.e. a custom-shader-trigger = cursor. Other values could be pane or window or <interval in seconds>, and so on I guess?

I'm assuming this would also allow the fps to go down after the cool down.

An example is cursor trailing functionality, which has been suggested it could become a core feature precisely as a way to improve efficiency. But that's currently not implemented and, in any case, will always fall short of the customization aspect.

[pluiedev]

This is a known area that could do with some improvements. Quoting from the docs on custom-shader-animation:

This can also be set to always, which will always run the animation loop regardless of whether the terminal is focused or not. The animation loop will still only run when custom shaders are used. Note that this will use more CPU per terminal surface and can become quite expensive depending on the shader and your terminal usage.

When we first merged the cursor trail PR Mitchell mentioned that we should implement cursor trails as a first-class feature rather than an available input for custom shaders since we would be able to optimize and only draw the animation when the cursor moves, but I think your idea of only ticking the animation depending on certain events could be a possible way forwards as well. I'm just not sure what other events we could include there (maybe we could introduce some sort of damage tracking as well?)

[mitchellh]

I do get why, though I'm not sure why it doesn't just peg it at maximum when running the shader (144Hz in my case). Beside the point I suppose?

On this specific point: On both macOS and Linux, we defer to the underlying system to tell us our vsync windows. macOS especially tends to use variable rates dictated by the power scheduler. In any case, we don't control this.