tdesktop
tdesktop copied to clipboard
telegramdesktop
Reconnect spinner burns CPU
Steps to reproduce
- Disconnect network
- Look at telegram or look at top/strace
Or, said differently, try to work somewhere without internet connection (and power supply).
Expected behaviour
Telegram should not burn CPU. In particular when it is not even visible (e.g. different workspace). Which it probably only can do because it is using X11 (Xwayland) rather than wayland (GNOME shell).
Easiest fix would likely be to just do a countdown that is only updated e.g. every 5 seconds instead of showing a spinner. At least when the window is not focused.
Configuration
Operating system: F32
Version of Telegram Desktop: 2.1.11
Installation source (Linux Only) - flatpak
Used theme: default
Reproducable on Gentoo GNU/Linux, Telegram 2.1.7, installation source - Gentoo package, DE - Plasma Wayland.
I am also seeing a lot of wakeups while just running and connected. This could be related if QT has a similar behaviour to GTK where spinners may cause wakeups (but no rendering) if they are not stopped in certain use cases.
Hey there!
This issue will be automatically closed in 7 days if there would be no activity. We therefore assume that the user has lost interest or resolved the problem on their own.
Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.
Thanks!
![stale[bot] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}
Still present on Ubuntu 20.04 when network connection goes down. Telegram uses 6-7 % CPU. Oftentimes something "snaps" all Telegram starts using 100% CPU. Even when I go back online, the CPU usage stays at 100%. The only remedy is to restart Telegram.
I literally woke up last night to the sound of my cpu because my internet went offline. it also uses ALL cores to make sure it is annoying enough. thanks telegram.
Hey there!
This issue was inactive for a long time and will be automatically closed in 30 days if there isn't any further activity. We therefore assume that the user has lost interest or resolved the problem on their own.
Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.
Thanks!
Hey there!
This issue was inactive for a long time and will be automatically closed in 30 days if there isn't any further activity. We therefore assume that the user has lost interest or resolved the problem on their own.
Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.
Thanks!
Hey there!
This issue was inactive for a long time and will be automatically closed in 30 days if there isn't any further activity. We therefore assume that the user has lost interest or resolved the problem on their own.
Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.
Thanks!
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Still the same behavior, also it some times cause my laptop to overheat and freeze, so I have to close tg when I am away from laptop.
@shtirlic , does this behaviour happen when your network connection goes down?
@themighty1 actually the debug process is quite hard for this issue, my scenario is like this: I lock my laptop with tg running in the background and in the morning I got frozen and hot laptop with all fans on max, in journalctl I do not see any suspicious errors or something bad around the projected freeze time, but for sure I saw iwd reconnection messages some time before. It might be that lost connection is not instantly spinning CPU to orbital speed just in time of disconnection, but somehow it triggers some deadlock in tg code a little bit later. Reconnection/Lost connection high CPU issues I have seen for years before, I saw this on Windows and macOS too. Currently my setup is: Arch Linux with KDE(x11). I will try to gather more info using audit logs and logging system usage/thermal/network activity.
Thanks for the description. I know it's a tall call but someone motivated enough could compile a debug version of tgdesktop and run it under a CPU profiler to see which function is responsible for the CPU loop.
I know it's a tall call but someone motivated enough could compile a debug version of tgdesktop and run it under a CPU profiler to see which function is responsible for the CPU loop.
I just looked in to doing this, but the build instructions don't work for Mac. For other devs, this is incredibly easy to reproduce for me on macOS:
- Open Telegram
- Go to System Preferences > Network > Advanced ... and set up a SOCKS proxy for an IP/port that hangs.
- See CPU spikes
Original reporter here. As I implied in my original report, the problem appears to be excessive redrawing. Just plain redrawing of a spinner ...
i.e. powertop says:
Usage Events/s Category Description
4.6 ms/s 72.9 Process [PID 967096] telegram-desktop --
and well, yeah, redrawing with 60Hz would be consistent with that. sysprof shows the CPU time is pretty much all spend drawing too:
So, really, just replace that reconnection spinner with something that is only updated once every few seconds at max.
And yes ... it could be that the desktop environment or QT is partially to blame here (e.g. window shouldn't actually get redrawn if it is completely obscured). But, maybe it would still be nice to solve it here in some way.
@benzea, Thanks for pointing out the animation. The app does some work even when interface animation is disabled in settings.
Here is the capture of sysprof.
The problem is CPU usage offline is higher than online. CPU usage is 0% of a CPU thread online, 25% offline w/ animation on, 4% w/ animation off for i5-11600KF. and 0/50/5 for i5-8265U. 5% CPU usages is a big load on laptop battery. It consumes as much energy as watching a movie, but doing nothing.
@yanovich oh, true. And in that case it seems to be mostly polling and killing QT timers. So, I guess stopping/starting some timer somewhere ... outch
Hey there!
This issue was inactive for a long time and will be automatically closed in 30 days if there isn't any further activity. We therefore assume that the user has lost interest or resolved the problem on their own.
Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.
Thanks!
still an issue on the latest tg desktop I still see some ~5-10% CPU usage like I reported 2 years ago.
you're lucky, it uses %1600 CPU on my system. fans still wake me up when there's a connection issue..
Sent from Proton Mail for iOS
On Wed, Dec 20, 2023 at 08:21, dan @.***(mailto:On Wed, Dec 20, 2023 at 08:21, dan < wrote:
still an issue on the latest tg desktop I still see some ~5-10% CPU usage like I reported 2 years ago.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
There's a bug in the Qt 6 RHI abstraction that it mis-uses QImage's CoW feature and causes a detach (copy) of entire window buffer on every repaint so the animation is perhaps consuming way more CPU on Wayland than on Windows/macOS/X11. I've patched Qt for official builds in 4.14.4 so it should consume not more than official builds for other systems. Can't help distro builds though.
Can't help distro builds though.
Can you post your qt patch? That would help...
Currently it consists of 4 patches: https://github.com/desktop-app/patches/blob/master/qtbase_6.6.1/0029-fix-backing-store-rhi-unneeded-copy.patch https://github.com/desktop-app/patches/blob/master/qtbase_6.6.1/0030-fix-backing-store-rhi-xcb-unneeded-copy.patch https://github.com/desktop-app/patches/blob/master/qtbase_6.6.1/0031-fix-backing-store-opengl-subimage-unneeded-copy.patch https://github.com/desktop-app/patches/blob/master/qtwayland_6.6.1/0009-fix-backing-store-rhi-unneeded-copy.patch But I think it could be made down to 2 patches: the fix-backing-store-opengl-subimage-unneeded-copy one + just remove the image.detach() from QBackingStoreDefaultCompositor::toTexture. This means less changes but fixing for all platforms at once (all Qt platforms affected but the current variant fixes only X11 and Wayland).