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.

Original 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.

Resolution

Fixed on eMuleBB main by app commit fd1a3489 (BUG-124 batch rolling log pane updates). The fix keeps the existing RichEdit panes and makes the rolling-retention path cheaper:

  • head trimming is deferred during log batches
  • accumulated visible-text trimming is applied in one chunk at batch flush
  • pending visible entries are appended under one captured selection and autoscroll state instead of one full AddLine path per log line
  • extra RichEdit text-limit slack lets normal batches append before fallback rebuild is required
  • visible retention is reduced to 2,000 normal log entries and 4,000 verbose log entries
  • hidden or invalidated panes rebuild once from the bounded model when they are materialized again

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

Regression coverage was added in test commit c85b138 (BUG-124 cover rolling log retention seam). The shared seam covers the retention constants, RichEdit text-limit slack, trim planning, pending-entry drop policy, and saturating character arithmetic without requiring a live MFC RichEdit control.

Acceptance Criteria

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

Validation

  • Native Release parity suite: passed, 747 passed / 0 failed / 243 skipped.
  • x64 Debug app build: passed.
  • x64 Release app build: passed.
  • Workspace validation: passed.
  • App build warnings were the existing unrelated C4191/C5219 warnings in ChatSelector.cpp, SharedFilesCtrl.cpp, and EmuleDlg.cpp; warning policy audit passed.