Text render performance question

[huacnlee]

layout_wrapped_line not fast enough, if there have a lot of texts to render.

Recently, I have going to find out the gpui-component table performance issues.

And then I found that:

• Case 1: When use ScrollWheel to scroll, the FPS can stabilize on 120 FPS.
• Case 2: When use Drag to scroll, the FPS will about 80 FPS.

CleanShot.2025-02-05.at.16.35.27.mp4

So, I used the samply to measure the performance.

git clone https://github.com/longbridge/gpui-component.git 
cd gpui-component
cargo build --release --example table
samply record ./target/release/examples/table

Then I found that maybe there problem caused by the text rendering.

Test Result

This link can visit the samply result: https://share.firefox.dev/4hHy1QY

The previous 4s - 28s is by ScrollWheel, after seconds are Drag.

Case 1: By ScrollWheel

In this case, the layout_wrapped_line cost is 5.8% (Plus left about 12%)

Case 2: By Drag

In this case is 34% (Actually if plus left one all cost will be about 50%)

---

I have read the source code of the layout_wrapped_line, there have a cache used previous frame.
But in drag scrolling case, it may always cache miss, because drag range is too large, so it is so many texts are not same.

zed/crates/gpui/src/text_system/line_layout.rs

Lines 492 to 519 in 8edcaec

	let previous_frame_entry = self.previous_frame.lock().wrapped_lines.remove_entry(key);
	if let Some((key, layout)) = previous_frame_entry {
	let mut current_frame = RwLockUpgradableReadGuard::upgrade(current_frame);
	current_frame
	.wrapped_lines
	.insert(key.clone(), layout.clone());
	current_frame.used_wrapped_lines.push(key);
	layout
	} else {
	drop(current_frame);
	let text = SharedString::from(text);
	let unwrapped_layout = self.layout_line::<&SharedString>(&text, font_size, runs);
	let wrap_boundaries = if let Some(wrap_width) = wrap_width {
	unwrapped_layout.compute_wrap_boundaries(text.as_ref(), wrap_width, max_lines)
	} else {
	SmallVec::new()
	};
	let layout = Arc::new(WrappedLineLayout {
	unwrapped_layout,
	wrap_boundaries,
	wrap_width,
	});
	let key = Arc::new(CacheKey {
	text,
	font_size,
	runs: SmallVec::from(runs),
	wrap_width,
	});

[huacnlee]

I have seen @osiewicz improved this method in #22566. I have done a check to confirm this change is included on my test.

[osiewicz]

This was more so a micro-optimization; we definitely invalidate more than necessary, but I'm not sure how much we can do about it without substantially changing guts of GPUI. For one I'm pretty sure we always re-layout the whole app on each frame, with few caches here and there to make perf slightly better.

Could you try using AnyView::cached on the items in your table? That might help a bit.

btw. I'm pretty sure that I didn't drag-and-scroll in the benchmark for #22566; I used a Page Down action.

[huacnlee]

Thanks of your advice, I will try the AnyView::cached today to see it how difference.

[huacnlee]

By your advice, we have tried to enable AnyView::cached in our application. This is not improved mush for scrolling case (When scrolling, the CPU usage will up to 100%).

But it is useful to reduce the CPU cost in some other cases (about reduce 3% - 10% CPU).

Our application have a data update in background, but some views may not have updates related by data. So this change will reduce render CPU. The previous version by no cache be always called render.

This is diff (Upper is no cache, Lower is new version):

[huacnlee]

In the scene in my Table, the rows and columns are already virtual lists, and the actual rendered cells are only about 400 cells in the demo area.

From the current performance, the FPS drop caused by more than 400 text rendering is a bit strange, and I also noticed that the CPU overhead during scrolling (including ScrollWheel) is also worth paying attention to (often reaching more than 70% CPU, so I have only recently analyzed this issue.

I have been comparing the performance differences between Zed and the Demo I wrote and our Application. It seems that because the Table and our actual Application UI have more elements than, the CPU usage will be higher than Zed (When there is operation: Zed is about 40%, mine is 70% - 100%), but the standby state is relatively normal.

[huacnlee]

#24373

I make an example for this case.

[huacnlee]

I have done a test. If add a period (10s) and then recycle cache, it can a little improve.

However, this 10s is not reasonable. I am not sure whether many characters will be rendered in 10s, resulting in excessive memory usage.

diff --git a/crates/gpui/src/text_system/line_layout.rs b/crates/gpui/src/text_system/line_layout.rs
index 360042d98e..c467b86480 100644
--- a/crates/gpui/src/text_system/line_layout.rs
+++ b/crates/gpui/src/text_system/line_layout.rs
@@ -7,6 +7,7 @@ use std::{
     hash::{Hash, Hasher},
     ops::Range,
     sync::Arc,
+    time::{Duration, Instant},
 };
 
 use super::LineWrapper;
@@ -397,6 +398,7 @@ pub(crate) struct LineLayoutCache {
 
 #[derive(Default)]
 struct FrameCache {
+    last_clean: Option<Instant>,
     lines: FxHashMap<Arc<CacheKey>, Arc<LineLayout>>,
     wrapped_lines: FxHashMap<Arc<CacheKey>, Arc<WrappedLineLayout>>,
     used_lines: Vec<Arc<CacheKey>>,
@@ -459,8 +461,16 @@ impl LineLayoutCache {
         let mut prev_frame = self.previous_frame.lock();
         let mut curr_frame = self.current_frame.write();
         std::mem::swap(&mut *prev_frame, &mut *curr_frame);
-        curr_frame.lines.clear();
-        curr_frame.wrapped_lines.clear();
+
+        // Keep frame cache 10 seconds.
+        // This for avoid text rendering performance issue when the text is changing frequently and reduce CPU usage.
+        if curr_frame.last_clean.map_or(true, |last| {
+            Instant::now().duration_since(last) > Duration::from_secs(10)
+        }) {
+            curr_frame.lines.clear();
+            curr_frame.wrapped_lines.clear();
+            curr_frame.last_clean = Some(Instant::now());
+        }
         curr_frame.used_lines.clear();
         curr_frame.used_wrapped_lines.clear();
     }

[huacnlee]

This seems to be a problem with the platform_text_system.layout_line call.

In the case of Table Cells, all the text is small and called multiple times (In generally, a table may have about 500 ~ 1000 times call this method).

[huacnlee]

zed/crates/gpui/src/elements/div.rs

Lines 1830 to 1835 in 69b9811

	window.on_mouse_event(move |_: &MouseMoveEvent, phase, window, _cx| {
	let hovered = hitbox.is_hovered(window);
	if phase == DispatchPhase::Capture && hovered != was_hovered {
	window.refresh();
	}
	});

This part of code, in Table or List cases, may have an improvement space.

If the TableRow and ListItem have hover style, this lines will always called window.refresh, then the all elements on the window will do full render, even them have cache. Because on scrolling, mouse is on the ListItem, it will touch the MouseMoveEvent.

This also exist in Zed project_panel, recent_projects etc..., if I am correct, this improvement can effectively reduce the CPU overhead of Zed during list scrolling. Currently is about 40% CPU on scrolling, maybe it can reduce to 20%.

How to test this side effect?

Add a println!("------------------- render project_panel") into ProjectPanel render method.

zed/crates/project_panel/src/project_panel.rs

Lines 4318 to 4320 in 69b9811

	impl Render for ProjectPanel {
	fn render(&mut self, window: &mut Window, cx: &mut Context<Self>) -> impl IntoElement {
	let has_worktree = !self.visible_entries.is_empty();

And then mouse move on some other area outside the ProjectPanel that have hover style, for example the Panel Tab or the Button on StatusBar. Every mouse move will show a print.

[huacnlee]

And here. When every time on ScrollWheel, will call window.refresh.

But this situation does not happen in Zed's Editor and Terminal. It seems that the Editor area does not use GPUI's scroll.

zed/crates/gpui/src/elements/div.rs

Lines 2132 to 2168 in 69b9811

	window.on_mouse_event(move |event: &ScrollWheelEvent, phase, window, cx| {
	if phase == DispatchPhase::Bubble && hitbox.is_hovered(window) {
	let mut scroll_offset = scroll_offset.borrow_mut();
	let old_scroll_offset = *scroll_offset;
	let delta = event.delta.pixel_delta(line_height);
	let mut delta_x = Pixels::ZERO;
	if overflow.x == Overflow::Scroll {
	if !delta.x.is_zero() {
	delta_x = delta.x;
	} else if overflow.y != Overflow::Scroll {
	delta_x = delta.y;
	}
	}
	let mut delta_y = Pixels::ZERO;
	if overflow.y == Overflow::Scroll {
	if !delta.y.is_zero() {
	delta_y = delta.y;
	} else if overflow.x != Overflow::Scroll {
	delta_y = delta.x;
	}
	}
	if !allow_concurrent_scroll && !delta_x.is_zero() && !delta_y.is_zero() {
	if delta_x.abs() > delta_y.abs() {
	delta_y = Pixels::ZERO;
	} else {
	delta_x = Pixels::ZERO;
	}
	}
	scroll_offset.y += delta_y;
	scroll_offset.x += delta_x;
	cx.stop_propagation();
	if *scroll_offset != old_scroll_offset {
	window.refresh();
	}
	}
	});

[huacnlee]

After thinking about it, it is indeed necessary to do window.refresh on hover and scroll due to the design of GPUI.