Wezterm: High CPU when using blinking cursor styles

[diefans]

Describe the bug

CPU is constantly at 15% on a freshly started wezterm

Environment (please complete the following information):

• OS: archlinux
• Frontend: OpenGL
• Version: wezterm 20200517-122836-92c201c6

To Reproduce

Start a wezterm

Configuration

local wezterm = require 'wezterm';

function font_with_fallback(name, params)
    local names = {
        name,
        "FiraCode Nerd Font",
    }
    return wezterm.font_with_fallback(names, params)
end

return {
    font = font_with_fallback("JetBrains Mono Medium"),
    font_size = 11.5,
    font_antialias = "Greyscale"
    font_hinting = "Full",
    },

    cursor_blink_rate = 300,
    default_cursor_style = "BlinkingBlock",
    scrollback_lines = 9999,

    color_schemes = {
        ["trilight"] = {
            background = "#120707",
            foreground = "#efeedc",
            cursor_bg = "#52ad70",
            cursor_fg = "#120707",
            cursor_border = "#e2d7d7",
            brights = {
                "#000000",
                "#c54e53",
                "#b9ca4a",
                "#e6c547",
                "#7aa6da",
                "#c397d8",
                "#70c0ba",
                "#dddddd"
            },
            ansi = {
                "#666666",
                "#cf3334",
                "#9ec400",
                "#e7c547",
                "#7aa6da",
                "#b77ee0",
                "#54ced6",
                "#ffffff"
            },
        }
    },
    color_scheme = "trilight",
}

Expected behavior

If nothing is happening, there should be much less CPU used

Additional context

here is an strace of the process:

wezterm.txt

[diefans]

I found out, if I comment out the color_schemes part of the config CPU is less than 1

[wez]

The main thing that affects this is the use of a blinking cursor style. Blinks cause additional invalidations and draw cycles based on your configured blink rate and that causes more CPU/GPU usage.

There's probably room for improvement!

Does that system have a GPU?

[wez]

I'm not seeing any obvious and easy ways to improve performance for this case; the invalidation causes the visible screen to be recomputed and sent to the GPU which is reasonably efficient for text processing updating at normal human rates and where the CPU utilization is bursty and feels worthwhile (because output is happening).

For the blink case we have to pay that same cost at the configured blink rate, even if nothing else has changed. Making that path faster would require making broader changes to optimize more; I'm not opposed to it happening, it's just not going to be a quick and easy couple of changes!

I did push a commit just now that can skip the invalidations when the window is not focused, so at least you'll only pay that cost for a single focused wezterm now.

[wez]

Heh, well it wasn't obvious but it was easy to fix once I traced it; the state tracking the last blink wasn't updating in the way that you'd expect which meant that after the first cursor_blink_rate interval we'd invalidate every 35ms.

The commit I just pushed corrects that and brings utilization down from about ~5% on my system to ~0.7%.

[diefans]

I still get a lot of -1 EAGAIN (Resource temporarily unavailable) in strace....mhhhh
wezterm.txt

[wez]

EAGAIN doesn't necessarily indicate an issue; can you confirm that the CPU utilization is improved?

[diefans]

@wez CPU is about 0.5% so I close this.... thanks!