Optimize editor rendering when clipped by parent containers #44995

as-cii · 2025-12-16T14:47:43Z

Summary

Optimizes editor rendering when an editor is partially clipped by a parent container (e.g., a List). The editor now only lays out and renders lines that are actually visible within the viewport, rather than all lines in the document.

Problem

When an AutoHeight editor with thousands of lines is placed inside a scrollable List (such as in the Agent Panel thread view), the editor would lay out all lines during prepaint, even though only a small portion was visible. Profiling showed that ~50% of frame time was spent in EditorElement::prepaint → LineWithInvisibles::from_chunks, processing thousands of invisible lines.

Solution

Calculate the intersection of the editor's bounds with the current content mask (which represents the visible viewport after all parent clipping). Use this to determine:

clipped_top_in_lines - how many lines are clipped above the viewport
visible_height_in_lines - how many lines are actually visible

Then adjust start_row and end_row to only include visible lines. The parent container handles positioning, so scroll_position remains unchanged for paint calculations.

Example

For a 3000-line editor where only 50 lines are visible:

Before: Lay out and render 3000 lines
After: Lay out and render ~50 lines

Testing

Verified the following scenarios work correctly:

Editor fully visible (no clipping)
Editor clipped from top
Editor clipped from bottom
Editor completely outside viewport (renders nothing)
Fractional line clipping at boundaries
Scrollable editors with internal scroll state inside a clipped container

Release Notes:

Improved agent panel performance when rendering large diffs.

When an AutoHeight editor is inside a scrollable List, only render the lines that are actually visible instead of all lines in the editor. Previously, a 3000-line editor would lay out all 3000 lines even when only ~50 were visible, causing significant performance issues.

The editor optimization uses window.content_mask().bounds to determine visible rows. In tests, the content mask defaults to the window's viewport size (1920x1043 from TestDisplay), not the draw size passed to cx.draw(). Fix by calling cx.simulate_resize() before drawing to ensure the window's viewport matches the intended draw size (3000x3000). Also removes debug eprintln! statements from investigation.

…44995)" This reverts commit 914b011. The optimization introduced a regression that causes the main thread to hang for 100+ seconds in certain scenarios. ## Analysis from spindump When a large AutoHeight editor is displayed inside a List (e.g., Agent Panel thread view), the clipping calculation can produce invalid row ranges: 1. `visible_bounds` from `window.content_mask().bounds` represents the window's content mask, not the intersection with the editor 2. When the editor is partially scrolled out of view, `clipped_top_in_lines` becomes extremely large 3. This causes `start_row` to be computed as an astronomically high value 4. `blocks_in_range(start_row..end_row)` then spends excessive time in `Cursor::search_forward` iterating through the block tree The spindump showed ~46% of samples (459/1001 over 10+ seconds) stuck in `BlockSnapshot::blocks_in_range()`, specifically in cursor iteration. ## Symptoms - Main thread unresponsive for 33-113 seconds - UI completely frozen - High CPU usage on main thread (10+ seconds of CPU time) - Force quit required to recover The original optimization goal (reducing line layout work for clipped editors) is valid, but the implementation needs to correctly calculate the intersection of editor bounds with the visible viewport, and ensure row calculations stay within valid ranges.

…45011) This reverts commit 914b011 (#44995). The optimization introduced a regression that causes the main thread to hang for **100+ seconds** in certain scenarios, requiring a force quit to recover. ## Analysis from spindump When a large `AutoHeight` editor is displayed inside a `List` (e.g., Agent Panel thread view), the clipping calculation can produce invalid row ranges: 1. `visible_bounds` from `window.content_mask().bounds` represents the window's content mask, not the intersection with the editor 2. When the editor is partially scrolled out of view, `clipped_top_in_lines` becomes extremely large 3. This causes `start_row` to be computed as an astronomically high value 4. `blocks_in_range(start_row..end_row)` then spends excessive time in `Cursor::search_forward` iterating through the block tree The spindump showed **~46% of samples** (459/1001 over 10+ seconds) stuck in `BlockSnapshot::blocks_in_range()`, specifically in cursor iteration. ### Heaviest stack trace ``` EditorElement::prepaint └─ blocks_in_range + 236 └─ Cursor::search_forward (459 samples) ``` ## Symptoms - Main thread unresponsive for 33-113 seconds before sampling even began - UI completely frozen - High CPU usage on main thread (10+ seconds of CPU time in the sample) - Force quit required to recover ## Path forward The original optimization goal (reducing line layout work for clipped editors) is valid, but the implementation needs to: 1. Correctly calculate the **intersection** of editor bounds with the visible viewport 2. Ensure row calculations stay within valid ranges (clamped to `max_row`) 3. Handle edge cases where the editor is completely outside the visible bounds Release Notes: - Fixed a hang that could occur when viewing large diffs in the Agent Panel

The editor optimization from #45077 uses window.content_mask().bounds to determine visible rows. In tests, the content mask defaults to the window's viewport size (1920x1043 from TestDisplay), not the draw size passed to cx.draw(). Fix by calling cx.simulate_resize() before drawing to ensure the window's viewport matches the intended draw size (3000x3000). This fix was originally part of #44995 but was lost when that PR was reverted in #45011.

Fixes the hang introduced in #44995 (which was reverted in #45011) and re-enables the optimization. ## Background PR #44995 introduced an optimization to skip rendering lines that are clipped by parent containers (e.g., when a large AutoHeight editor is inside a scrollable List). This significantly improved performance for large diffs in the Agent Panel. However, #45011 reverted this change because it caused the main thread to hang for 100+ seconds in certain scenarios, requiring a force quit to recover. ## Root Cause The original analysis in #45011 suggested that visible_bounds wasn’t being intersected properly, but that was incorrect—the intersection via with_content_mask works correctly. The actual bug: when an editor is positioned above the visible viewport (e.g., scrolled past in a List), the clipping calculation produces a start_row that exceeds max_row: 1. Editor’s bounds.origin.y becomes very negative (e.g., -10000px) 2. After intersection, visible_bounds.origin.y is at the viewport top (e.g., 0) 3. clipped_top_in_lines = (0 - (-10000)) / line_height = huge number 4. start_row = huge number, but end_row is clamped to max_row 5. This creates an invalid range where start_row > end_row This caused two different failures depending on build mode: - Debug mode: Panic from subtraction overflow in Range<DisplayRow>::len() - Release mode: Integer wraparound causing blocks_in_range to enter an infinite loop (the 100+ second hang) ## Fix Simply clamp start_row to max_row, ensuring the row range is always valid: ```rs let start_row = cmp::min( DisplayRow((scroll_position.y + clipped_top_in_lines).floor() as u32), max_row, ); ``` ## Testing Added a regression test that draws an editor at y=-10000 to simulate an editor that’s been scrolled past in a List. This would panic in debug mode (and hang in release mode) before the fix. Release Notes: - Improved agent panel performance when rendering large diffs.

This brings the terminal element's viewport culling in line with the editor optimization in PR #44995 and the fix in PR #45077. ## Problem When a terminal is inside a scrollable container (e.g., the Agent Panel thread view), it would render ALL cells during prepaint, even when the terminal was entirely outside the viewport. This caused unnecessary CPU usage when multiple terminal tool outputs existed in the Agent Panel. ## Solution Calculate the intersection of the terminal's bounds with the current content_mask (the visible viewport after all parent clipping). If the intersection has zero area, skip all cell processing entirely. ### Important distinction between content modes: - **ContentMode::Scrollable**: Cells use the terminal's internal coordinate system with negative line numbers for scrollback history. We cannot filter cells by screen-space row numbers, so we render all cells when visible. The early-exit for zero intersection handles the offscreen case. - **ContentMode::Inline**: Cells use 0-based line numbers (no scrollback). We can filter cells to only those in the visible row range, using the same logic that existed before but now extracted into a helper function with proper bounds clamping to prevent the hang bug from PR #45077. ## Testing Added comprehensive unit tests for: - compute_visible_row_range edge cases - Cell filtering logic for Inline mode - Line/i32 comparison behavior Manually verified: - Terminal fully visible (no clipping) - Terminal clipped from top/bottom - Terminal completely outside viewport (renders nothing) - Scrollable terminals with scrollback history work correctly Release Notes: - Improved Agent Panel performance when terminals are scrolled offscreen.

@as-cii

This brings the terminal element's viewport culling in line with the editor optimization in PR #44995 and the fix in PR #45077. ## Problem When a terminal is inside a scrollable container (e.g., the Agent Panel thread view), it would render ALL cells during prepaint, even when the terminal was entirely outside the viewport. This caused unnecessary CPU usage when multiple terminal tool outputs existed in the Agent Panel. ## Solution Calculate the intersection of the terminal's bounds with the current content_mask (the visible viewport after all parent clipping). If the intersection has zero area, skip all cell processing entirely. ### Three code paths 1. **Offscreen** (`intersection.size <= 0`): Early exit, process 0 cells 2. **Fully visible** (`intersection == bounds`): Fast path, stream cells directly (no allocation) 3. **Partially clipped**: Group cells by line, skip/take visible rows only ### Key insight: filter by screen position, not buffer coordinates The previous approach tried to filter cells by `cell.point.line` (terminal buffer coordinates), which breaks in Scrollable mode where cells can have negative line numbers for scrollback history. The new approach filters by **screen position** using `chunk_by(line).skip(N).take(M)`, which works regardless of the actual line numbers because we're filtering on enumerated line group index. ## Testing Added comprehensive unit tests for: - Screen-position filtering with positive lines (Inline mode) - Screen-position filtering with negative lines (Scrollable mode with scrollback) - Edge cases (skip all, positioning math) - Unified filtering works for both modes Manually verified: - Terminal fully visible (no clipping) ✓ - Terminal clipped from top/bottom ✓ - Terminal completely outside viewport ✓ - Scrollable terminals with scrollback history ✓ - Selection/interaction still works ✓ Release Notes: - Improved Agent Panel performance when terminals are scrolled offscreen. /cc @as-cii

@as-cii

…dustries#45537) This brings the terminal element's viewport culling in line with the editor optimization in PR zed-industries#44995 and the fix in PR zed-industries#45077. ## Problem When a terminal is inside a scrollable container (e.g., the Agent Panel thread view), it would render ALL cells during prepaint, even when the terminal was entirely outside the viewport. This caused unnecessary CPU usage when multiple terminal tool outputs existed in the Agent Panel. ## Solution Calculate the intersection of the terminal's bounds with the current content_mask (the visible viewport after all parent clipping). If the intersection has zero area, skip all cell processing entirely. ### Three code paths 1. **Offscreen** (`intersection.size <= 0`): Early exit, process 0 cells 2. **Fully visible** (`intersection == bounds`): Fast path, stream cells directly (no allocation) 3. **Partially clipped**: Group cells by line, skip/take visible rows only ### Key insight: filter by screen position, not buffer coordinates The previous approach tried to filter cells by `cell.point.line` (terminal buffer coordinates), which breaks in Scrollable mode where cells can have negative line numbers for scrollback history. The new approach filters by **screen position** using `chunk_by(line).skip(N).take(M)`, which works regardless of the actual line numbers because we're filtering on enumerated line group index. ## Testing Added comprehensive unit tests for: - Screen-position filtering with positive lines (Inline mode) - Screen-position filtering with negative lines (Scrollable mode with scrollback) - Edge cases (skip all, positioning math) - Unified filtering works for both modes Manually verified: - Terminal fully visible (no clipping) ✓ - Terminal clipped from top/bottom ✓ - Terminal completely outside viewport ✓ - Scrollable terminals with scrollback history ✓ - Selection/interaction still works ✓ Release Notes: - Improved Agent Panel performance when terminals are scrolled offscreen. /cc @as-cii

@as-cii

This brings the terminal element's viewport culling in line with the editor optimization in PR #44995 and the fix in PR #45077. ## Problem When a terminal is inside a scrollable container (e.g., the Agent Panel thread view), it would render ALL cells during prepaint, even when the terminal was entirely outside the viewport. This caused unnecessary CPU usage when multiple terminal tool outputs existed in the Agent Panel. ## Solution Calculate the intersection of the terminal's bounds with the current content_mask (the visible viewport after all parent clipping). If the intersection has zero area, skip all cell processing entirely. ### Three code paths 1. **Offscreen** (`intersection.size <= 0`): Early exit, process 0 cells 2. **Fully visible** (`intersection == bounds`): Fast path, stream cells directly (no allocation) 3. **Partially clipped**: Group cells by line, skip/take visible rows only ### Key insight: filter by screen position, not buffer coordinates The previous approach tried to filter cells by `cell.point.line` (terminal buffer coordinates), which breaks in Scrollable mode where cells can have negative line numbers for scrollback history. The new approach filters by **screen position** using `chunk_by(line).skip(N).take(M)`, which works regardless of the actual line numbers because we're filtering on enumerated line group index. ## Testing Added comprehensive unit tests for: - Screen-position filtering with positive lines (Inline mode) - Screen-position filtering with negative lines (Scrollable mode with scrollback) - Edge cases (skip all, positioning math) - Unified filtering works for both modes Manually verified: - Terminal fully visible (no clipping) ✓ - Terminal clipped from top/bottom ✓ - Terminal completely outside viewport ✓ - Scrollable terminals with scrollback history ✓ - Selection/interaction still works ✓ Release Notes: - Improved Agent Panel performance when terminals are scrolled offscreen. /cc @as-cii

…ed-industries#45011) This reverts commit 914b011 (zed-industries#44995). The optimization introduced a regression that causes the main thread to hang for **100+ seconds** in certain scenarios, requiring a force quit to recover. ## Analysis from spindump When a large `AutoHeight` editor is displayed inside a `List` (e.g., Agent Panel thread view), the clipping calculation can produce invalid row ranges: 1. `visible_bounds` from `window.content_mask().bounds` represents the window's content mask, not the intersection with the editor 2. When the editor is partially scrolled out of view, `clipped_top_in_lines` becomes extremely large 3. This causes `start_row` to be computed as an astronomically high value 4. `blocks_in_range(start_row..end_row)` then spends excessive time in `Cursor::search_forward` iterating through the block tree The spindump showed **~46% of samples** (459/1001 over 10+ seconds) stuck in `BlockSnapshot::blocks_in_range()`, specifically in cursor iteration. ### Heaviest stack trace ``` EditorElement::prepaint └─ blocks_in_range + 236 └─ Cursor::search_forward (459 samples) ``` ## Symptoms - Main thread unresponsive for 33-113 seconds before sampling even began - UI completely frozen - High CPU usage on main thread (10+ seconds of CPU time in the sample) - Force quit required to recover ## Path forward The original optimization goal (reducing line layout work for clipped editors) is valid, but the implementation needs to: 1. Correctly calculate the **intersection** of editor bounds with the visible viewport 2. Ensure row calculations stay within valid ranges (clamped to `max_row`) 3. Handle edge cases where the editor is completely outside the visible bounds Release Notes: - Fixed a hang that could occur when viewing large diffs in the Agent Panel

Fixes the hang introduced in zed-industries#44995 (which was reverted in zed-industries#45011) and re-enables the optimization. ## Background PR zed-industries#44995 introduced an optimization to skip rendering lines that are clipped by parent containers (e.g., when a large AutoHeight editor is inside a scrollable List). This significantly improved performance for large diffs in the Agent Panel. However, zed-industries#45011 reverted this change because it caused the main thread to hang for 100+ seconds in certain scenarios, requiring a force quit to recover. ## Root Cause The original analysis in zed-industries#45011 suggested that visible_bounds wasn’t being intersected properly, but that was incorrect—the intersection via with_content_mask works correctly. The actual bug: when an editor is positioned above the visible viewport (e.g., scrolled past in a List), the clipping calculation produces a start_row that exceeds max_row: 1. Editor’s bounds.origin.y becomes very negative (e.g., -10000px) 2. After intersection, visible_bounds.origin.y is at the viewport top (e.g., 0) 3. clipped_top_in_lines = (0 - (-10000)) / line_height = huge number 4. start_row = huge number, but end_row is clamped to max_row 5. This creates an invalid range where start_row > end_row This caused two different failures depending on build mode: - Debug mode: Panic from subtraction overflow in Range<DisplayRow>::len() - Release mode: Integer wraparound causing blocks_in_range to enter an infinite loop (the 100+ second hang) ## Fix Simply clamp start_row to max_row, ensuring the row range is always valid: ```rs let start_row = cmp::min( DisplayRow((scroll_position.y + clipped_top_in_lines).floor() as u32), max_row, ); ``` ## Testing Added a regression test that draws an editor at y=-10000 to simulate an editor that’s been scrolled past in a List. This would panic in debug mode (and hang in release mode) before the fix. Release Notes: - Improved agent panel performance when rendering large diffs.

@as-cii

…dustries#45537) This brings the terminal element's viewport culling in line with the editor optimization in PR zed-industries#44995 and the fix in PR zed-industries#45077. ## Problem When a terminal is inside a scrollable container (e.g., the Agent Panel thread view), it would render ALL cells during prepaint, even when the terminal was entirely outside the viewport. This caused unnecessary CPU usage when multiple terminal tool outputs existed in the Agent Panel. ## Solution Calculate the intersection of the terminal's bounds with the current content_mask (the visible viewport after all parent clipping). If the intersection has zero area, skip all cell processing entirely. ### Three code paths 1. **Offscreen** (`intersection.size <= 0`): Early exit, process 0 cells 2. **Fully visible** (`intersection == bounds`): Fast path, stream cells directly (no allocation) 3. **Partially clipped**: Group cells by line, skip/take visible rows only ### Key insight: filter by screen position, not buffer coordinates The previous approach tried to filter cells by `cell.point.line` (terminal buffer coordinates), which breaks in Scrollable mode where cells can have negative line numbers for scrollback history. The new approach filters by **screen position** using `chunk_by(line).skip(N).take(M)`, which works regardless of the actual line numbers because we're filtering on enumerated line group index. ## Testing Added comprehensive unit tests for: - Screen-position filtering with positive lines (Inline mode) - Screen-position filtering with negative lines (Scrollable mode with scrollback) - Edge cases (skip all, positioning math) - Unified filtering works for both modes Manually verified: - Terminal fully visible (no clipping) ✓ - Terminal clipped from top/bottom ✓ - Terminal completely outside viewport ✓ - Scrollable terminals with scrollback history ✓ - Selection/interaction still works ✓ Release Notes: - Improved Agent Panel performance when terminals are scrolled offscreen. /cc @as-cii

…ed-industries#45011) This reverts commit 914b011 (zed-industries#44995). The optimization introduced a regression that causes the main thread to hang for **100+ seconds** in certain scenarios, requiring a force quit to recover. ## Analysis from spindump When a large `AutoHeight` editor is displayed inside a `List` (e.g., Agent Panel thread view), the clipping calculation can produce invalid row ranges: 1. `visible_bounds` from `window.content_mask().bounds` represents the window's content mask, not the intersection with the editor 2. When the editor is partially scrolled out of view, `clipped_top_in_lines` becomes extremely large 3. This causes `start_row` to be computed as an astronomically high value 4. `blocks_in_range(start_row..end_row)` then spends excessive time in `Cursor::search_forward` iterating through the block tree The spindump showed **~46% of samples** (459/1001 over 10+ seconds) stuck in `BlockSnapshot::blocks_in_range()`, specifically in cursor iteration. ### Heaviest stack trace ``` EditorElement::prepaint └─ blocks_in_range + 236 └─ Cursor::search_forward (459 samples) ``` ## Symptoms - Main thread unresponsive for 33-113 seconds before sampling even began - UI completely frozen - High CPU usage on main thread (10+ seconds of CPU time in the sample) - Force quit required to recover ## Path forward The original optimization goal (reducing line layout work for clipped editors) is valid, but the implementation needs to: 1. Correctly calculate the **intersection** of editor bounds with the visible viewport 2. Ensure row calculations stay within valid ranges (clamped to `max_row`) 3. Handle edge cases where the editor is completely outside the visible bounds Release Notes: - Fixed a hang that could occur when viewing large diffs in the Agent Panel

Fixes the hang introduced in zed-industries#44995 (which was reverted in zed-industries#45011) and re-enables the optimization. ## Background PR zed-industries#44995 introduced an optimization to skip rendering lines that are clipped by parent containers (e.g., when a large AutoHeight editor is inside a scrollable List). This significantly improved performance for large diffs in the Agent Panel. However, zed-industries#45011 reverted this change because it caused the main thread to hang for 100+ seconds in certain scenarios, requiring a force quit to recover. ## Root Cause The original analysis in zed-industries#45011 suggested that visible_bounds wasn’t being intersected properly, but that was incorrect—the intersection via with_content_mask works correctly. The actual bug: when an editor is positioned above the visible viewport (e.g., scrolled past in a List), the clipping calculation produces a start_row that exceeds max_row: 1. Editor’s bounds.origin.y becomes very negative (e.g., -10000px) 2. After intersection, visible_bounds.origin.y is at the viewport top (e.g., 0) 3. clipped_top_in_lines = (0 - (-10000)) / line_height = huge number 4. start_row = huge number, but end_row is clamped to max_row 5. This creates an invalid range where start_row > end_row This caused two different failures depending on build mode: - Debug mode: Panic from subtraction overflow in Range<DisplayRow>::len() - Release mode: Integer wraparound causing blocks_in_range to enter an infinite loop (the 100+ second hang) ## Fix Simply clamp start_row to max_row, ensuring the row range is always valid: ```rs let start_row = cmp::min( DisplayRow((scroll_position.y + clipped_top_in_lines).floor() as u32), max_row, ); ``` ## Testing Added a regression test that draws an editor at y=-10000 to simulate an editor that’s been scrolled past in a List. This would panic in debug mode (and hang in release mode) before the fix. Release Notes: - Improved agent panel performance when rendering large diffs.

@as-cii

…dustries#45537) This brings the terminal element's viewport culling in line with the editor optimization in PR zed-industries#44995 and the fix in PR zed-industries#45077. ## Problem When a terminal is inside a scrollable container (e.g., the Agent Panel thread view), it would render ALL cells during prepaint, even when the terminal was entirely outside the viewport. This caused unnecessary CPU usage when multiple terminal tool outputs existed in the Agent Panel. ## Solution Calculate the intersection of the terminal's bounds with the current content_mask (the visible viewport after all parent clipping). If the intersection has zero area, skip all cell processing entirely. ### Three code paths 1. **Offscreen** (`intersection.size <= 0`): Early exit, process 0 cells 2. **Fully visible** (`intersection == bounds`): Fast path, stream cells directly (no allocation) 3. **Partially clipped**: Group cells by line, skip/take visible rows only ### Key insight: filter by screen position, not buffer coordinates The previous approach tried to filter cells by `cell.point.line` (terminal buffer coordinates), which breaks in Scrollable mode where cells can have negative line numbers for scrollback history. The new approach filters by **screen position** using `chunk_by(line).skip(N).take(M)`, which works regardless of the actual line numbers because we're filtering on enumerated line group index. ## Testing Added comprehensive unit tests for: - Screen-position filtering with positive lines (Inline mode) - Screen-position filtering with negative lines (Scrollable mode with scrollback) - Edge cases (skip all, positioning math) - Unified filtering works for both modes Manually verified: - Terminal fully visible (no clipping) ✓ - Terminal clipped from top/bottom ✓ - Terminal completely outside viewport ✓ - Scrollable terminals with scrollback history ✓ - Selection/interaction still works ✓ Release Notes: - Improved Agent Panel performance when terminals are scrolled offscreen. /cc @as-cii

cla-bot bot added the cla-signed The user has signed the Contributor License Agreement label Dec 16, 2025

as-cii merged commit 914b011 into main Dec 16, 2025
23 checks passed

as-cii deleted the editor-perf-uniform-list branch December 16, 2025 15:59

nathansobo mentioned this pull request Dec 16, 2025

Revert "Optimize editor rendering when clipped by parent containers" #45011

Merged

as-cii mentioned this pull request Dec 17, 2025

Fix editor hang when positioned above viewport #45077

Merged

nathansobo mentioned this pull request Dec 22, 2025

Optimize terminal rendering when clipped by parent containers #45537

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Optimize editor rendering when clipped by parent containers #44995

Optimize editor rendering when clipped by parent containers #44995

Uh oh!

as-cii commented Dec 16, 2025 •

edited

Loading

Uh oh!

Labels

2 participants

Uh oh!

Optimize editor rendering when clipped by parent containers #44995

Optimize editor rendering when clipped by parent containers #44995

Uh oh!

Conversation

as-cii commented Dec 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Problem

Solution

Example

Testing

Uh oh!

Labels

2 participants

as-cii commented Dec 16, 2025 •

edited

Loading