resizable: Fix panel resizing flickering

[hlcfan]

Description

It seems after the gpui-base separation, resizing a panel then repaint can cause a flickering in the UI. The fix schedules a repaint after container size adjusted after current draw cycle.

Be

Screenshot

Before

Screen.Recording.2026-09-02.at.10.19.53.AM.mov

After

Screen.Recording.2026-09-02.at.10.30.32.AM.mov

Break Changes

NA

How to Test

• mixed_sizing_is_stable_between_resize_and_followup_frame

Checklist

• I have read the CONTRIBUTING document and followed the guidelines.
• Reviewed the changes in this PR and confirmed AI generated code (If any) is accurate.
• Passed cargo run for story tests related to the changes.
• Tested macOS, Windows and Linux platforms performance (if the change is platform-specific)

[huacnlee]

This obviously is a monkey patch, not a really to solve the root problem.

[huacnlee]

I pushed a follow-up commit to this branch (f6198f2e) rather than asking for another round. The diagnosis in this PR is right and the deferral is necessary — I only narrowed what gets deferred.

window.refresh() sets Window::refreshing, and the view element cache in gpui's view.rs reuses a prepaint only when !window.refreshing. So the settling frame re-renders and re-lays-out every .cached(...) view in the window. This repo has exactly one such call site — crates/ui/src/dock/tab_panel.rs:730 — and the dock builds its splits from resizable groups (dock_area.rs:1398), so the cost lands precisely where resizable groups are used most and panels are heaviest.

A deferred cx.notify() on the state entity schedules the same frame without touching the cache: Invalidator::invalidate_view marks the window dirty once draw_phase is back to None, and a cached view still re-renders when its own bounds actually change. Measured with a .cached(...) sibling view, one container resize goes from one forced re-render to zero, and your mixed_sizing_is_stable_between_resize_and_followup_frame still passes unchanged.

I also corrected the comment. A refresh raised mid-draw is not coalesced into that draw — Window::refresh is guarded by if self.invalidator.not_drawing(), so it is dropped outright. And a notify raised mid-draw records the view as dirty without setting dirty, so no frame is scheduled. Those are two different failure modes, and the deferral is what fixes both.

One addition: the group's state can come from use_keyed_state (which installs an observer turning a state change into a view notify) or from with_state, which the dock uses at dock_area.rs:1443 and which has no such observer. I added caller_owned_state_settles_on_the_same_frame to cover that second path, since your test only exercises the first. Without the fix it settles at 440px and then drops to 360px on the next frame; with it, both frames read 360px.

Two things I did not change, for you to decide:

1. adjust_to_container_size rescales every panel proportionally, including one the caller pinned with .size(px(240.)). On an 800 → 1200 container that sidebar becomes 360px. ResizablePanel's own doc comment presents .flex_none() as the way to hold a fixed width, but the adjustment does not consult it. This PR does not introduce that, it just makes it happen immediately and on every resize instead of on some later repaint.
2. assert_ne!(settled_frame, before) in the new test encodes that behavior as the contract, so whoever fixes (1) will have to delete the assertion. Worth a comment saying it is descriptive rather than intended.

---

🤖 Review assisted by Claude Code