Intel Mac issues CPU/UI

[OlaProeis]

I tested the Intel version but :

1, there is a constant high CPU usage when I open the app

There is Constant high CPU usage when I open the app

2, synchronized scrolling isn’t working.

3, the UI use Windows Close/Minimize/Maximize icons instead of macOS (not a big deal for me tho on this one)

Originally posted by @4goodapp in #2 (comment)

[OlaProeis]

Hi @4goodapp,

Thank you for the detailed report! In v0.2.5 (just released), we've addressed the CPU usage issue:

Fixed in v0.2.5:

• Idle repaint scheduling to reduce CPU usage when the app is not actively being used

Still tracking for v0.2.6:

• Synchronized scrolling on Intel Macs
• Native macOS window controls (traffic lights) (we have a custom header, that is why you see it without the macos buttons, its intended, will see if we can integrate them at some point)

Could you please test v0.2.5 and let us know if the CPU usage has improved? The sync scrolling and window controls are on our roadmap for the next release.

[4goodapp]

Hello @OlaProeis,

I just test it but unfortunately it still uses 99% CPU.
Even when not in use.

[OlaProeis]

This is now tracked as a priority item for v0.2.6. Could you try one thing to help us debug?

1. Run Ferrite from terminal: ./ferrite --log-level debug
2. Let it idle for 30 seconds
3. Share any repeating log messages

This might help identify what's triggering the constant repaints.

[4goodapp]

Here it Is:

ferrite_macos_intel_log.txt

[OlaProeis]

Thanks for the detailed log! That was incredibly helpful for tracking this down.

What we found:
The log analysis revealed that 99.9% of the output (48,850 lines in 22 seconds) was coming from debug statements in the list item renderer: the same items being logged 4-5 times per frame at ~60fps. The app should be throttling to ~10fps when idle, but something in Rendered mode was triggering continuous repaints.

Root cause identified:
The rendered editor's scroll area content was using Sense::hover() which caused egui to request immediate repaints whenever the mouse moved over the content area. This bypassed the 100ms idle throttling completely - egui's request_repaint() (immediate) takes priority over request_repaint_after(100ms) (scheduled).

Coming in v0.2.5.1:

• Removed the verbose debug logging that was adding CPU overhead through string formatting
• Fixed the continuous repaint issue - Changed scroll area sensing from Sense::hover() to Sense::focusable_noninteractive() which allows proper idle throttling (~10fps instead of ~60fps)
• Added FPS diagnostic logging (debug builds) to help verify the fix

Expected results:

Idle CPU usage should drop to <5% (from 100%)
Frame rate when idle should be ~10fps (100ms intervals) instead of ~60fps
The app should only actively repaint when there's actual user interaction
Would appreciate if you could test the v0.2.5.1 release when it's available and let us know if the CPU usage improves!

[OlaProeis]

@4goodapp

v0.2.5.1 is now available with several CPU improvements.

The changes I mentioned over are included:

• Removed verbose debug logging overhead
• Fixed continuous repaint issue (Sense::hover → Sense::focusable_noninteractive)
• Added tiered idle intervals (light idle at 100ms/~10fps, deep idle at 500ms/~2fps)

Expected results:

• Idle CPU should drop from ~100% to <5%
• Frame rate when idle: ~2-10fps instead of ~60fps

Please test and let us know how it goes! The sync scrolling and window controls are still tracked for v0.2.6.

[4goodapp]

Working much better … No more constant high CPU usage.