roboomp
809a8a348d
EventController.handleEvent rebuilt the editor's status-line top border synchronously on every session event via updateEditorTopBorder(). During a long-running eval that fires 5-10 events/s, each rebuild ran StatusLine.getTopBorder → #buildSegmentContext → getCachedContextBreakdown → session.getContextUsage → estimateTokens (with JSON.stringify per toolCall block) — the render pipeline is throttled to ~30 fps, so most rebuilds were dropped before painting. Combined with a scheduler that collapsed cadenceDelay to zero whenever a frame overran the 33ms budget, the TUI busy-looped at ~40-50% CPU. Fix: - Editor gains setTopBorderProvider(): a lazy builder invoked once per editor render. InteractiveMode installs it in the constructor and on setEditorComponent, so the rebuild coalesces to the render tempo regardless of event rate. - Delete updateEditorTopBorder wrapper (now equivalent to ui.requestRender) and inline every call site. - Add adaptive render backpressure: a frame that exceeds MIN_RENDER_INTERVAL_MS inflates the next scheduling delay to 2 * last_frame_cost, capped at 200 ms, targeting a 50% render duty cycle instead of pinning the CPU at t=0. New regression tests: - editor-top-border-provider.test.ts: provider fires exactly once per render, wins over eager setTopBorder, falls back when cleared, gets the correct availableWidth. - adaptive-render-backpressure.test.ts: cheap frames keep the 33 ms cadence, a slow frame idles proportionally, pathological frames are capped at 200 ms. Verified with bun test packages/tui/test (all 246 relevant tests pass) and bun test packages/coding-agent/test/modes (455 tests pass). Three pre-existing agent-session-handoff snapcompact failures on main are unrelated (snapcompactSupportedChars binding). Fixes #4145
55 lines
2.0 KiB
TypeScript
55 lines
2.0 KiB
TypeScript
import { afterEach, beforeEach, describe, expect, it, vi } from "bun:test";
|
|
import { Settings } from "@oh-my-pi/pi-coding-agent/config/settings";
|
|
import { SelectorController } from "@oh-my-pi/pi-coding-agent/modes/controllers/selector-controller";
|
|
import { beginSettingsTest, restoreSettingsTestState, type SettingsTestState } from "./helpers/settings-test-state";
|
|
|
|
let settingsState: SettingsTestState | undefined;
|
|
|
|
beforeEach(async () => {
|
|
settingsState = beginSettingsTest();
|
|
await Settings.init({ inMemory: true });
|
|
});
|
|
|
|
afterEach(() => {
|
|
restoreSettingsTestState(settingsState);
|
|
settingsState = undefined;
|
|
});
|
|
|
|
describe("selector setting side effects", () => {
|
|
it("refreshes the status line when git integration changes at runtime", () => {
|
|
const updateSettings = vi.fn();
|
|
const requestRender = vi.fn();
|
|
const controller = new SelectorController({
|
|
statusLine: { updateSettings },
|
|
ui: { requestRender },
|
|
} as unknown as ConstructorParameters<typeof SelectorController>[0]);
|
|
|
|
Settings.instance.override("git.enabled", false);
|
|
controller.handleSettingChange("git.enabled", false);
|
|
|
|
expect(updateSettings).toHaveBeenCalledWith(
|
|
expect.objectContaining({
|
|
preset: Settings.instance.get("statusLine.preset"),
|
|
leftSegments: Settings.instance.get("statusLine.leftSegments"),
|
|
rightSegments: Settings.instance.get("statusLine.rightSegments"),
|
|
}),
|
|
);
|
|
// The setting-change side effect is a single render request — the lazy
|
|
// top-border provider rebuilds during paint (#4145).
|
|
expect(requestRender).toHaveBeenCalledTimes(1);
|
|
});
|
|
|
|
it("invalidates the UI and requests a repaint when tui.tight changes", () => {
|
|
const invalidate = vi.fn();
|
|
const requestRender = vi.fn();
|
|
const controller = new SelectorController({
|
|
ui: { invalidate, requestRender },
|
|
} as unknown as ConstructorParameters<typeof SelectorController>[0]);
|
|
|
|
controller.handleSettingChange("tui.tight", true);
|
|
|
|
expect(invalidate).toHaveBeenCalledTimes(1);
|
|
expect(requestRender).toHaveBeenCalledTimes(1);
|
|
});
|
|
});
|