High CPU usage while moving cursor

[git-f0x]

This occurs while the mouse cursor is moving inside the window, or while the typing cursor is moving (e.g. while typing a command or moving through a text file).

[git-f0x]

The cosmic-text update hasn't perceivably changed the CPU usage in either case, so this might be more related to graphics/rendering (edit: or something completely different, since I don't think there should be any rendering by the terminal while the mouse is moving over it).

[MoSal]

@git-f0x

Maybe this is stating the obvious, but if it's CPU usage, maybe profiling will be helpful.

Building with

cargo build --profile release-with-debug

Running with

./target/release-with-debug/cosmic-term

And profiling, while triggering the issue, with something like:

perf top -p `pgrep -f '\./target/release-with-debug/cosmic-term$'` -g -F200

[git-f0x]

Thank you for the detailed instructions. I'm not sure if I'm doing something wrong, but perf reports the highest usage while triggering the issue sometimes by [unknown], or [JIT] tid xxxx, or [kernel], or libvulkan_lvp.so, and the increase is way lower than htop shows (while the issue isn't being triggered, htop shows barely any usage by cosmic-term, while perf shows 2-3% for the top 6 items; and when the issue is triggered, htop shows above 40% across all cores, while in perf there's barely any change, though libvulkan_lvp.so, [unknown], or [JIT] tid xxxx tend to be at the top). Not sure if it's relevant but there's a message on the bottom of perf that says Too slow to read ring buffer (change period ...). Changing the period up or down didn't make much of a difference.

[mmstick]

You have to build the terminal with debug set to true in the release profile in the Cargo manifest. Calls going into Vulkan are a symptom of the redraws.

[git-f0x]

I did build with the release-with-debug profile above and it has debug=true in Cargo.toml. Should I add

[profile.release]
debug = true

to the file instead and then build --release?

[MoSal]

@git-f0x

That shouldn't be necessary.

• You can try replacing -g with --call-graph dwarf in the perf command, or without both, and see if you get anything more useful.
• Run with WGPU_BACKEND=gl ./target/release-with-debug/cosmic-term to see if it's a Vulkan issue.
• Build with --no-default-features to see how a software renderer would fare.

[git-f0x]

Running with WGPU_BACKEND=gl or building with --no-default-features does expose more info in perf, and the CPU usage in htop is less spread out among cores (sometimes reaching 80% on one core), but is possibly less when added together. The usage in perf doesn't change much between triggering the issue, then idling, and triggering it again, but I'm not familiar with how perf works (if it might save some kind of average). Here's its output with the items that were highlighted in red that I copied at one point (sometimes the usage on some of these reached around 30%):

+   19.57%    19.57%  cosmic-term       [.] tiny_skia::pipeline::lowp::mask_u8
+   16.21%    16.21%  cosmic-term       [.] tiny_skia::pipeline::lowp::load_dst
+    9.18%     9.18%  cosmic-term       [.] swash::scale::cff::outlines::Outlines::draw
+    8.95%     8.95%  cosmic-term       [.] tiny_skia::pipeline::lowp::store
+    5.92%     5.92%  cosmic-term       [.] tiny_skia::pipeline::lowp::source_over
+    5.43%     5.43%  cosmic-term       [.] <memmap2::Mmap as core::convert::AsRef<[u8]>>::as_ref

Also something that might be relevant, I'm running this on a system that doesn't support Vulkan (I'll test this on my main system when I'm able to, if needed).

[MoSal]

@git-f0x

• tiny_skia is the software renderer.
• I didn't notice that you mentioned libvulkan_lvp.so earlier. That's Vulkan software based emulation which, I would assume, is very slow. Are you sure the problem persists when using the GL backend? If it does, are you sure you have the right packages installed? The output of glxinfo|grep 'OpenGL' would be helpful.
• perf accumulates results since the start of profiling. So it's best to keep triggering the issue while it's running. Also, the percentages shown are relative to the total taken by the process. You can still see high percentages even if the process is using 0.1% of a core.

[git-f0x]

Running the previously compiled binary with GL yields similar results as running the one compiled with --no-default-features.

~$ glxinfo | grep OpenGL
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) HD Graphics (ILK)
OpenGL version string: 2.1 Mesa 24.0.0-1pop0~1706872735~22.04~0fa430c
OpenGL shading language version string: 1.20
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 2.0 Mesa 24.0.0-1pop0~1706872735~22.04~0fa430c
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16
OpenGL ES profile extensions:

[MoSal]

Oh, GL backend won't work with OpenGL 2.1/OpenGL ES 2.0. I didn't realize your GPU was that old/limited.

(Non-emulated) software rendering is probably the best choice here. Whether it would be good/usable enough, I don't know.

[git-f0x]

This is on a 14-year-old laptop (COSMIC feels faster on it than GNOME or Plasma). I'll test this on my main system (with RX 570) in a few days, if this issue isn't present on your end.

[git-f0x]

I tested the other libcosmic apps that use wgpu now, and all exhibit the same high CPU usage when anything is rendered (cosmic-settings doesn't use wgpu and has a relatively minor increase in CPU usage when the cursor is moved over the window). Should I close this issue since it doesn't seem to be related to cosmic-term, but wgpu?

[git-f0x]

On my main system, htop reports around 35% CPU usage by cosmic-term (from almost none) while the cursor is moving. Perf:

  Children      Self  Shared Object                Symbol
+   10.30%     9.89%  cosmic-term                  [.] <std::collections::hash::map::DefaultHasher as core::hash::Hasher>::write
+    8.34%     7.96%  cosmic-term                  [.] glyphon::text_render::TextRenderer::prepare_with_depth
+    7.70%     7.60%  cosmic-term                  [.] lru::LruCache<K,V,S>::peek
+    5.01%     4.78%  cosmic-term                  [.] lru::LruCache<K,V,S>::promote
+    4.13%     3.41%  cosmic-term                  [.] core::hash::BuildHasher::hash_one
+    2.86%     2.50%  cosmic-term                  [.] cosmic_text::layout::LayoutGlyph::physical

[git-f0x]

I'll close this since moving the cursor in Nautilus and Firefox can reach 60% usage on one core (with around 30-40% by cosmic-comp, reported by htop).