-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
High CPU usage when accesskit enabled #4527
Comments
Hello @sebastiano-barrera, First, I'm assuming you are not running any assistive technology on your system, so AccessKit should not send data through D-Bus. This was fixed in AccessKit/accesskit#324. Even then, your application likely contain a lot of widgets that should be ignored by assistive technologies. Due to a limitation in AccessKit this used to generate unnecessary D-Bus trafic. This was fixed in AccessKit/accesskit#411. To see if updating egui's dependency on AccessKit will fix your issue, you can try depending on this fork: https://github.com/mwcampbell/egui/tree/accesskit-0.14-winit-0.29. Does this help? |
Assuming I patched my Cargo.toml correctly (commit), it seems not to have much of an effect: (The screenshot was taken while doing the same "scrolly" test as in the video in the original post.) |
Thanks @sebastiano-barrera for trying my suggestion. What concerns me here is that recent versions of the Could you please execute this command to see if accessibility is turned on on your system? busctl --user get-property org.a11y.Bus /org/a11y/bus org.a11y.Status IsEnabled If you are not running any assistive technology, I will try running your application on my side as soon as possible to diagnose what is putting so much load onto the system when accessibility is requested. |
Thank you for taking the time to look at this. The command you suggest does return Also, now that you suggest it, if the app's implementation can cause this problem, then there is a good chance that that's what's happening. I'm an egui noob if there ever was one. (In this case, I just wish this was better pointed out in the docs somewhere; maybe that can be my contribution later.) If you want to try it, it should be sufficient to clone the repo and go with: cargo run -p mcjs_tools -- ./mcjs_vm/test-resources/json5/test_parse.mjs Let me know if I can be of any support. This is a hobby project, so unfortunately no thought whatsoever was put into onboarding or user-friendliness... |
@sebastiano-barrera Assuming you're still using my accesskit-0.14-winit-0.29 branch of egui, try using |
In the commit you linked above you have updated egui and eframe to their 0.27 version. The proper dependencies are inside the What you need to do is to replace: egui = "0.27"
eframe = "0.27" By: egui = { git = "https://github.com/mwcampbell/egui", branch = "accesskit-0.14-winit-0.29" }
eframe = { git = "https://github.com/mwcampbell/egui", branch = "accesskit-0.14-winit-0.29" } Then you will need to patch egui_tiles so it uses the same version of egui. I achieved this by cloning egui_tiles, making it depend on @mwcampbell's fork then updating your Cargo.toml to depend on this local version: egui_tiles = { path = "../../egui_tiles" } With this I can already see that no D-Bus activity happen when I don't enable any assistive technology and the system load seem to be on par with a build of your app without AccessKit. I would appreciate if you could confirm. |
Done, and confirmed. (Although, CPU usage reliably hovers around ~60% instead of 40-50% like in the other case.) I'll admit I'm not so familiar with this mechanism in Cargo, but this surprised me. As far as I can tell, |
Happy to hear that @sebastiano-barrera. Just to make sure, the 40-50% CPU load you mention was measured with the patched dependencies? |
The 40-50% CPU load was observed with the first "test commit" I linked (sebastiano-barrera/mcjs@4980384). 60% is with the latest attempt like you suggest, with my app's and egui_tiles' Cargo.toml changed "directly" (without Full disclosure, I'm pretty sure the difference is reliable to observe, but I think it's acceptable after all, and I can't rule out a measurement artifact (I'm really just eyeballing htop). |
Sorry @mwcampbell, I missed your comment earlier. Your suggestion pushed me to solve the doubt I had about
Judging by the Adding accesskit [...] line, this is equivalent to what you had in mind, right? Commit c61d8765 is the latest, at the time of writing, from the winit-0.29-backport branch. At any rate, the resulting commit (sebastiano-barrera/mcjs@9e3b23a) seems to have fixed the issue. With this commit I see 40-50% CPU usage, as good as the "disabled accesskit" commit that I posted initially (sebastiano-barrera/mcjs@4980384). This might have "just" been a detour due to my incorrect application of the changes to Cargo.toml. |
Oh sorry, I think I misunderstood this package patching feature. It seem that the correct dependencies are pulled with sebastiano-barrera/mcjs@9e3b23a. Should be fixed by #4466 then. |
With #4849 merged, this issue should be solved for everyone. |
Describe the bug
In my app based on egui and eframe, the CPU usage is very high as long as the accesskit feature is enabled. By disabling it, the CPU usage remains under much more acceptable levels, and app itself runs much smoother as well.
(I'm available to work on the bug myself. I'd love some suggestions though; I don't quite see how accesskit/D-Bus traffic could cause this much resource consumption, however much it is.)
To Reproduce
Steps to reproduce the behavior:
Expected behavior
CPU usage "acceptable" (say, <50%) even while the app is continuously updating (e.g. while scrolling).
Videos
Look at the CPU% column:
Accesskit off, CPU stays < 50%
accesskit.off.cpu.usage.lower.mp4
Accesskit on, CPU stays ~200%
accesskit.on.cpu.usage.high.mp4
Desktop:
Additional context
I also have some
perf
profiles taken that point at a decent % of call stacks involving functions called accesskit::* and zbus::*. It's quite large, so I'll provide it only if you reckon it's useful.The text was updated successfully, but these errors were encountered: