drag the window on GNOME 42 X11 cause very high CPU usage and window stuck

[Sherlock-Holo]

Is there an existing issue for this?

• [X] I have searched the existing issues.

Is this issue related to iced?

• [X] My hardware is compatible and my graphics drivers are up-to-date.

What happened?

my codes

I use iced master branch with pure feature

[dependencies.iced]
version = "0.3"
features = ["pure", "debug"]
path = "/home/sherlock/git/fork/iced"

When I drag the window, the window moves very slow, it looks likes it sucks, like this video

My CPU is AMD R9 5900x and GPU is RTX 3070

When I am dragging the window, I notice the GPU usage is not high, only 25%(looks from nvtop which I ssh to my PC from my Phone) but the CPU usage is 100%(can look from nvtop and htop)

What is the expected behavior?

it should be smooth, like when I running the hello-window example

Version

master

Operative System

Linux

Do you have any log output?

No response

[hecrj]

Thanks for filing an issue! Some questions:

• The video you linked doesn't seem to be a video file. Could you attach it directly in the GitHub issue?
• When you say "dragging the window" do you mean resizing it?
• Are you using release mode?
• You have text_multithreading enabled, which means text rasterization will leverage all of your CPU cores. Have you tried disabling it?
• Can your code that reproduces the issue be simplified further? Is the Scrollable necessary to reproduce it?

[Sherlock-Holo]

https://user-images.githubusercontent.com/10096425/164350771-0aede66a-5a03-4a38-a7eb-440a015498ad.mp4

drag the window: I means move the window by cursor

I am running with --release

I have tried disable the text_multithreading, actually I didn't enable it at first, until I found this problem and try to set something to improve the performance and i found text_multithreading, but that doesn't work

[Sherlock-Holo]

Thanks for filing an issue! Some questions:

• The video you linked doesn't seem to be a video file. Could you attach it directly in the GitHub issue?
• When you say "dragging the window" do you mean resizing it?
• Are you using release mode?
• You have text_multithreading enabled, which means text rasterization will leverage all of your CPU cores. Have you tried disabling it?
• Can your code that reproduces the issue be simplified further? Is the Scrollable necessary to reproduce it?

I write a simple example

use iced::pure::widget::{Container, Text};
use iced::pure::{Element, Sandbox};
use iced::Settings;

pub fn run() {
    Empty::run(Settings::default()).unwrap()
}

pub struct Empty;

impl Sandbox for Empty {
    type Message = ();

    fn new() -> Self {
        Self
    }

    fn title(&self) -> String {
        "empty".to_string()
    }

    fn update(&mut self, _message: Self::Message) {}

    fn view(&self) -> Element<'_, Self::Message> {
        Container::new(Text::new("test")).into()
    }
}
``` and the problem still exists, of cause run with `--release`

[Sherlock-Holo]

Thanks for filing an issue! Some questions:

• The video you linked doesn't seem to be a video file. Could you attach it directly in the GitHub issue?
• When you say "dragging the window" do you mean resizing it?
• Are you using release mode?
• You have text_multithreading enabled, which means text rasterization will leverage all of your CPU cores. Have you tried disabling it?
• Can your code that reproduces the issue be simplified further? Is the Scrollable necessary to reproduce it?

I write a simple example

use iced::pure::widget::{Container, Text};
use iced::pure::{Element, Sandbox};
use iced::Settings;

pub fn run() {
    Empty::run(Settings::default()).unwrap()
}

pub struct Empty;

impl Sandbox for Empty {
    type Message = ();

    fn new() -> Self {
        Self
    }

    fn title(&self) -> String {
        "empty".to_string()
    }

    fn update(&mut self, _message: Self::Message) {}

    fn view(&self) -> Element<'_, Self::Message> {
        Container::new(Text::new("test")).into()
    }
}
``` and the problem still exists, of cause run with `--release`

even just use the Space::new(Length::Fill, Length::Fill).into()

[Sherlock-Holo]

I use cargo flamegrah to capture some data, hope it could help you find out what causes this problem @hecrj

[flxzt]

I think I have the same issue, simply running any example causes very high CPU usage when dragging the window. The performance while the window is still is perfectly fine. I am on X11, Gnome 42, Fedora 36 with Nvidia drivers. I'd be happy to provide more info / logs, whatever is needed.

[vess-dev]

Do any other applications cause this too? I'm on Gnome 42 and hit the same issue with windows other than Iced ones.

[Sherlock-Holo]

I have tried on archlinux gnome x11 with intel graphics hd620, the problem disappear.

I also try druid which also a rust gui library, no this problem.

maybe the problem is in iced Window related codes？

[Sherlock-Holo]

I create a new flamegraph for the empty example https://github.com/iced-rs/iced/issues/1312#issuecomment-1105215254

it seems more clear than the first one

[Sherlock-Holo]

I check the flamegraph and see the most cpu cost is about glx, so I search glx from arch wiki, then I found a tool glxgears, run it will display a gear, I drag the window, the window stuck.

I think iced use glx so this problem appeared

in archlinux wiki, set the env __GLX_VENDOR_LIBRARY_NAME=mesa MESA_LOADER_DRIVER_OVERRIDE=zink GALLIUM_DRIVER=zink can make glxgears smooth, but iced still has the problem :(

[Sherlock-Holo]

I try winit and wgpu example, none of them will stuck when drag the window...

@hecrj could you help us find out what cause this problem, or tell us what more info you need

[Sherlock-Holo]

https://bitcointalk.org/index.php?topic=180658.0

in this Misiolap guest

nvidia opencl library enters loop which checks if the execution of opencl program has ended

compile his codes and use it through LD_PRELOAD=/tmp/ttt/libsleep.so ./target/release/gui_learn (I compile it at /tmp)

when dragging the window, it doesn't stuck anymore.

this is very hacking... I still want a better, not much hack way to solve this problem, because wgpu and winit example doesn't have this problem.

@flxzt maybe you can try this way, check if it works for you

[TheGlitch76]

I'm able to reproduce the symptoms of this issue on Fedora 37 and GNOME 43 with a Nvidia GTX 1660. The WGPU backend is slightly better than the glow backend, but they both are unacceptably slow.

I tried recording the issue, but OBS refused to do it!

[Bash-09]

I had this issue running on Ubuntu with Gnome 42.5 using an RTX 3070 with the nvidia-470 drivers. Issue was resolved when I changed to the open source drivers or nvidia-525 drivers.