High idle CPU usage (~25-30%) on macOS

[eval-exec]

Problem

@georgealbert report:

Neomacs uses ~25-30% CPU when idle on macOS (MacBook Air Intel 2020).

Reports

• Originally reported in Does it support MacOS? #22 (comment)
• Still present as of commit 9f9899b

Expected behavior

Idle CPU usage should be near 0% when no user input is occurring and no animations are running.

Likely cause

The render loop may be polling or redrawing continuously instead of blocking/sleeping when there are no pending events or frame updates.

Environment

• macOS, MacBook Air Intel 2020
• Commit: 9f9899b

[eval-exec]

@georgealbert Hello, when you start Neomacs with -Q, is the CPU usage still high while it’s idle?

[georgealbert]

Yes, CPU usage is still high with -Q. macOS version is 15.7.3

[eval-exec]

Investigation on Linux (x86_64, AMD Radeon RX 7900 XTX)

Measured idle CPU with ./src/emacs -Q and per-thread /proc/[pid]/task/[tid]/stat sampling:

Process totals (2-second intervals while idle):

• sample1→sample2: +11 ticks → ~5.5% single-core CPU
• sample2→sample3: +10 ticks → ~5% single-core CPU

Per-thread breakdown (2s delta):

• Render thread: utime 66→81 (+15 ticks, ~7.5% single-core CPU) — this is the hot thread
• Main Emacs thread: stable, ~0% CPU
• All other 85 threads: 0 ticks — fully idle

Conclusion: The render thread event loop is busy-looping or polling too frequently when idle. On macOS Intel (2-4 cores), 7.5% of one core would show as ~25-30% total CPU, matching the reported behavior.

Need to check the winit event loop / frame polling code in render_thread/mod.rs for a missing wait_for_events or too-aggressive poll_events cadence.

[eval-exec]

Fixed in commits 85569823 and 889fa036.

Root cause: ~50 draw_effect! call sites in glyphs.rs unconditionally set needs_continuous_redraw = true after each effect, even when the effect was disabled and produced zero vertices. This forced a permanent 240fps render loop (4ms WaitUntil) instead of idle polling.

Fix: Added a continuous arm to the draw_effect! macro that only sets needs_continuous_redraw = true when the effect actually produces non-empty vertices. Converted all ~50 affected call sites to use this new arm.

Result on Linux (AMD Radeon RX 7900 XTX):

• Render thread idle CPU: 0.4% (was ~7.5%)
• ~19x reduction

macOS should see a similar proportional improvement (from ~25-30% down to low single digits). @georgealbert could you verify with the latest main?

[georgealbert]

commit 4d7fed, CPU usage is still high.

[eval-exec]

I will reproduce it on a macos virual machine env... 🍎

[eval-exec]

Launched a macos-15 virtual machine using https://github.com/sickcodes/Docker-OSX
... start investigating....

[eval-exec]

Hello, @georgealbert

Could you capture a macOS CPU profile so we can pinpoint the hotspot?

Please run these steps on the machine that reproduces high CPU:

1. Confirm xctrace is available:

   xcrun xctrace list templates | rg "Time Profiler|CPU Profiler"
   

2. Start Neomacs and reproduce the high-CPU state.
3. Record a 30s trace by attaching to the running process:

     PID=$(pgrep -x emacs | head -n1)
     xcrun xctrace record \
       --template "Time Profiler" \
       --attach "$PID" \
       --time-limit 30s \
       --output "$HOME/Desktop/neomacs-highcpu.trace"

4. Zip the trace:

     ditto -c -k --sequesterRsrc --keepParent \
       "$HOME/Desktop/neomacs-highcpu.trace" \
       "$HOME/Desktop/neomacs-highcpu.trace.zip"

5. Upload neomacs-highcpu.trace.zip here (or share a link).

Also include:

• macOS version (exact, e.g. 14.7.4)
• Intel or Apple Silicon
• Neomacs commit SHA

[georgealbert]

• macOS version: 15.7.3
• intel
• commit 4d7fed

neomacs-highcpu.trace.zip

[eval-exec]

@georgealbert Thank you for uploading neomacs-highcpu.trace.zip.

Could you please export this trace to XML on your Mac and upload the XML files here? That will let us inspect hotspots directly. (It's hard to use xcode application stuff on my macos virtual machine)

xcrun xctrace export \
  --input "$HOME/Desktop/neomacs-highcpu.trace" \
  --toc \
  --output "$HOME/Desktop/neomacs-toc.xml"

Then export the Time Profiler table:

xcrun xctrace export \
  --input "$HOME/Desktop/neomacs-highcpu.trace" \
  --xpath '/trace-toc/run[@number="1"]/data/table[@schema="time-profile"]' \
  --output "$HOME/Desktop/neomacs-time-profile.xml"

If time-profile is not the exact schema name in your trace, please use the schema shown in neomacs-toc.xml.

Please upload both files:

• neomacs-toc.xml
• neomacs-time-profile.xml

Thanks.

[georgealbert]

neomacs-time-profile.xml.zip
neomacs-toc.xml

[eval-exec]

Thanks @georgealbert — I parsed the uploaded XML trace.

Key findings from this 30s Time Profiler capture:

• Main thread is on-CPU for most of the capture (~26s sampled):
  • Main Thread 0x45f530: 26,375 samples
• Dominant path is continuous render-loop work:
  • run_render_loop -> window_event -> render_frame_glyphs
  • Frequent Surface::get_current_texture / acquire_texture / -[CAMetalLayer nextDrawable]
• Significant cost in per-frame Metal resource churn:
  • IOAccelResourceCreate, -[MTLIOAccelResource init...], and matching dealloc paths
• App-side hotspots include:
  • render_frame_glyphs
  • render_scroll_indicators (with create_buffer_init in hot stacks)
• Transition effects are not the main culprit here (detect_transitions/render_transitions are very low).

So this confirms: macOS is still effectively rendering continuously in idle/high-frequency mode, and Metal resource creation/destruction cost is amplifying CPU use.

Could you run one quick check and report CPU delta:

(neomacs-scroll-indicator-mode -1)

If CPU drops significantly, we can prioritize fixing scroll-indicator buffer reuse / draw path first; if not, we’ll focus on the remaining continuous-redraw trigger logic.