Skip to content

Log panes can nearly freeze the UI under high-volume output

Summary

The Server window log panes can make the UI nearly unresponsive when enough log data is visible or arriving quickly.

Current main already has partial protection: normal and verbose panes use CHTRichEditCtrl::EnableRollingLogWindow, queued log messages are capped, and queued flushes call BeginLogBatchUpdate / EndLogBatchUpdate. The remaining risk is that the visible RichEdit control is still edited line-by-line. Once the rolling window is full, each new visible line may also remove text from the head before appending at the tail, which is expensive under heavy logging.

Current Mainline Evidence

Relevant current paths:

  • srchybrid/ServerWnd.cpp enables rolling windows for logbox and debuglog.
  • srchybrid/HTRichEditCtrl.cpp keeps the bounded deque but still mutates the visible RichEdit one line at a time.
  • srchybrid/emule.cpp batches queue drains, but the RichEdit work inside the batch still performs repeated append and trim operations.
  • srchybrid/Log.cpp has a separate bounded recent-log buffer for REST, which does not solve the desktop pane rendering cost.

The eMuleAI reference tree does not provide a better ready-made fix for this specific issue; its log panes are closer to the older unbounded RichEdit path.

Intended Fix Direction

Keep the current RichEdit panes for the first remediation and make the existing rolling-retention path cheaper:

  • defer head-trimming during log batches
  • apply accumulated visible-text trimming in chunks instead of per appended line
  • keep extra text-limit slack so a batch can append briefly before trim applies
  • reduce visible retention to a practical bounded history, for example 2,000 normal log entries and 4,000 verbose entries
  • preserve current autoscroll behavior so a user who scrolled up is not forced back to the bottom

Disk logging should remain governed by the existing log-to-disk settings and must not be capped by the visible pane limit.

Acceptance Criteria

  • [ ] High-volume normal and verbose logging does not make the main UI nearly freeze while the Server window log pane is visible.
  • [ ] The RichEdit rolling window trims in bounded chunks or at batch end, not once per full-window appended line.
  • [ ] Existing status-bar, notifier, log-to-disk, Save Log, and legacy web log behavior remains compatible with the bounded visible history.
  • [ ] A small native seam test covers the retention constants and deferred trim policy without requiring a live MFC RichEdit control.
  • [ ] Workspace validation and scoped native/app builds pass.