macOS: Typing indicators cause high CPU & GPU usage

[Shnub]

• [x] I have searched open and closed issues for duplicates

---

Bug Description

On both installations of macOS that I'm running Signal Desktop on (one 10.14.6 on Intel and one 11.2.2 on Apple ARM), CPU and GPU usage is very low when Signal is idle, but whenever a typing indicator is displayed, it jumps to curiously high values. This happens always; the indicator is never displayed without processor usage spiking. It doesn't matter whether the indicator appears in a visible conversation or just in the conversation list.

Crucially, this happens not only when the app is visible, but even when it is hidden or the window closed. Consequently, energy usage is now much higher than it used to be, dependent of course on how often and how long people compose messages.

This behavior started only recently, though unfortunately I can't say when exactly. It certainly wasn't an issue a year ago.

Steps to Reproduce

1. Observe processor usage while Signal is idle.
2. Wait till someone types a message and a typing indicator is displayed. (Signal window can be open, hidden, or closed.)

Actual Result:

High CPU and GPU usage.

Expected Result:

Processor usage not much higher than in idle state.

Screenshots

Signal processor usage when idle:

Signal processor usage while typing indicator is visible (no other discernible activity):

Platform Info

Signal Desktop Version: 1.40.1

Operating System: macOS 10.14.6 & 11.2.2

Linked Device Version: iOS 13.7

Signal Version on Linked Device: 5.5.0.18

Link to Debug Log

https://debuglogs.org/b79ff08e7f9c01cd844475995f85b19dcd8016caa8508dc308dfe658af531053

Wasn't quite fast enough, but scroll up to time 22:01:29, which should correspond to the time the problem occurred according to the screenshot filenames above (one hour difference likely Central European vs. Greenwich Time). At 22:02:02, the problem is gone again.

[sampumon]

For me, on a 2014 MacBook Air i7, cpu usage is so high that I know someone is typing when the fan ramps up 🌪️

Curiously WindowServer goes most berserk from this, hitting 80~90% cpu usage (normally less than 10%).

[scottnonnenberg-signal]

The CSS involved in animating a typing indicator is here: https://github.com/signalapp/Signal-Desktop/blob/db27a36e72ee7fc0d0a18d19642324822e26ca65/stylesheets/_modules.scss#L5387-L5436

Really doesn't seem like it should cause the behavior you're seeing, but perhaps there's something we could do to massage that a bit? If anyone would like to dig in, that would be appreciated! We need your help because we can't reproduce this on our machines!

[sampumon]

It does not seem to be the css, but javascript/react. I'm getting 5fps frames and lots of red-striped tasks on dev tools profiler. Exactly where this happens gets a bit lost in call stacks…

would this saved profile help you? It starts when typing indicator active, and ends few seconds after. I turned screenshots off, so no sensitive information..? 🤔

signal-desktop-typing-profile.zip

[scottnonnenberg-signal]

@sampumon Thanks for that profile. What exact version of the app were you running with that log? Because it includes references to specific source file lines, that information would really help.

[sampumon]

@scottnonnenberg oh yeah sorry, latest non-beta that is v1.40.1 💙

[sampumon]

Oh I just realised that this happens also when Signal window is closed 🦉

[Shnub]

Oh I just realised that this happens also when Signal window is closed 🦉

Yes, visible, hidden or closed window makes no difference. Also, the typing animation need not even be visible when the window is open; if you start a search for a conversation where the other party is not typing (so that the standard conversation list is not shown and thus no typing indicators there), then let someone from another conversation type (so there is also no typing indicator at the end of the active conversation), processor usage still spikes.

Also, I can confirm that the Window Server process is most affected, with CPU usage even higher than the GPU helper process.

Lastly, just to make sure, I disabled typing indicators on my mobile device and after the new setting had propagated to Signal Desktop, the problem was gone. Re-enabled the option and it was right back again.

[ardarandir]

Is this issue still persisting under new Signal 5.0.0? Otherwise this bug could be closed.

[sampumon]

Is still present on Signal 5.0.0, and also I upgraded to bigSUR 11.2.3.

And on 5.0.0, Signal Helper (Renderer) is using around 4% CPU all the time, as reported on beta thread and #5192.

[Shnub]

Confirmed, behavior is unchanged vs. 1.40.1.

[MrEbbinghaus]

Still happening with Signal 5.3.0 on macOS 11.4 (20F71)

[IngaFeick]

Still happening on macOS 11.1 with 5.5.0. In my case the problem started appearing just very recently, with the latest Signal update that I ran a couple of days ago.

[flibbles]

Can confirm. The best indicator I have that someone is typing to me is my laptop fan. CPU usages spikes up to 60% for those three little dots.

[scottnonnenberg-signal]

@flibbles This bug is about 4% CPU usage when the typing indicator is animating. 60% CPU usage is something else. Please enter a new bug, add debug logs, and provide as much information as you can about your system and its hardware.

[flibbles]

My laptop is very ganky. Nearly a decade old. (...And I may have also been running other stuff at the time which I didn't account for. Let's revise my number down to 30-40%)

But it is this bug, unless there is another which causes my computer to sound like an Apache helicopter only when someone is typing to me. The CPU usage correlates exactly with those dots.

[MrEbbinghaus]

@scottnonnenberg-signal It definitely went higher than 4% for me. The screenshot in the issue show up to 40%, which is around what I experienced as well (on a 6-core i7).

Seems like in version 5.7.0 the typing indicator is missing?? My friend next to me is typing a message for a minute and the indicator doesn't show up.

[scottnonnenberg-signal]

@flibbles @MrEbbinghaus Debug logs and computer hardware details would still be interesting. There's just timer-related code running, as well as pure CSS animation for that typing indicator. Perhaps it's that chromium/electron isn't able to hardware accelerate that animation as it does on other computers?

[MrEbbinghaus]

@scottnonnenberg-signal It's a 2018 15" MacBook Pro running macOS 11.4 CPU: Intel Core i7-8750H GPU: Radeon Pro 555X (I encountered the issue while plugged in, so this would do the rendering.)

I was about to get the debug logs, but as I said, it seems like my current signal version (v5.7.0, updated today) doesn't show typing indicators, and therefore I can't reproduce the issue now. :-/

[MrEbbinghaus]

@scottnonnenberg-signal This is what it looks like, when someone is typing:

Here is the debug log: https://debuglogs.org/9d4375bd6a7cf21af77237ad2143fc79566c44f868f07249a6d789998d3d6169.gz

[scottnonnenberg-signal]

I just did a test with our 'storybook' tool, where we can render our components in the browser. Chrome 91 uses a not-inconsequential amount of CPU on my dev machine with just the typing animation looping.

What if we disabled this kind of animation (and others) if you choose 'reduced animation' in your OS? More information here: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion#user_preferences

Would that be enough?

[sampumon]

It would be an okay reduction, but I don't think anyone here is running their OS in reduced animation mode, and that typing indicator really shouldn't use any noticeable resources on a less than ten years old computer. Something is not right there.

[Shnub]

Agreed, a user should not be forced to use a system-wide setting with potentially dozens of unwanted effects just to deal with a bug in Signal Desktop.

@scottnonnenberg-signal Not sure what you mean by "not-inconsequential amount of CPU", but people here have documented between 30 and 200 % CPU usage just for that animation. That is one or two orders of magnitude greater than what I would call "not-inconsequential", so perhaps what you are seeing in your test is not actually the bug in question. Anyway, I'd find even single-digit CPU usage barely acceptable for something as basic as that animation, and we are very far even from that.

[MrEbbinghaus]

I copied Signals CSS into an HTML file to play with it.

I can't figure out, what's going on. Firefox seems to be even worse than Chrome with up to 70% CPU usage!

If anyone wants a go here is the gist https://gist.github.com/MrEbbinghaus/b71c006e2e0f97c7af4b42e0904fc42f

[sampumon]

@MrEbbinghaus, for me both Chrome and Firefox are around 15%. Having developer tools open in Firefox uses more cpu than the actual page.

As I said on comment 4, the problem seems to be not css, but some javascript running at the same time.

[MrEbbinghaus]

@sampumon I doubt that JS is the problem. The CSS animation in the Gist above is causing ~20% CPU without devtools open. There is no JS involved.

If I disable the keyframes in the devtools or switch to another tab, the CPU load is gone.

[sampumon]

Yes but when someone is typing on Signal, it's 60% or more, so for me at least four times the cpu usage than just css. And profiler shows lots of javascript running. And this even if Signal's window is closed.

Haven't checked since v1.40.1 though, but based on others here, it's still pretty much the same.

[indutny-signal]

I copied Signals CSS into an HTML file to play with it.

I can't figure out, what's going on. Firefox seems to be even worse than Chrome with up to 70% CPU usage!

If anyone wants a go here is the gist https://gist.github.com/MrEbbinghaus/b71c006e2e0f97c7af4b42e0904fc42f

Thank you so much for putting this into a gist. Could you give a try to a slightly modified version to see if it helps at all: https://gist.github.com/indutny-signal/8ab1fbefc35c5e63bfd43220a7b01b27 ?

[sampumon]

@indutny-signal, your gist is the same ~15% for me.

I checked with v5.7.1, and it's the same as v1.40.1 when someone is typing:

Sometimes (Renderer) is more, sometimes (GPU) is more, totaling around 60..80%. No difference if window open or closed. WindowServer floats between 50% and 100%.

Here's debug log; latest typings start at 2021-07-01T09:54:06.820Z.

Ps. lost the link to one debug log; any way to restore it? 😅

[indutny-signal]

Reported issue to Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1225652 . Let's see what they think about it. As you have seen yourself the animation in question is very simple and shouldn't consume that much CPU!

Sorry this happens to you!

[sampumon]

@indutny-signal, the animation is ~15%, someone typing in Signal (incl. animation) is 60..80%.

That 15% I'm fine with, it is surprisingly high, but at least it's the same for Chrome and Firefox and not really a bug in Signal. The problem is what ever else going on for Signal to use 60..80%, blasting away mine and other 5y old compu's fans.

[adsche]

Is this still being worked on? I was very surprised to see that Signal.app was responsible for 1/3 of battery usage while I was not using it at all. The window was closed but when I opened it, an animated sticker was visible. It seems like that animation was rendered in the background all the time, even though the window was closed.

[varjolintu]

Similar problems here. With Apple Silicon laptop Signal Desktop 6.26.0 has a background process "Signal Helper (Renderer)" which constantly takes 40-50% of CPU even when the application is just in idle state.

[scottnonnenberg-signal]

We've made a change to improve this in the latest beta - please consider installing it and seeing if it improves CPU usage for you: https://support.signal.org/hc/articles/360007318471-Signal-Beta

[varjolintu]

We've made a change to improve this in the latest beta - please consider installing it and seeing if it improves CPU usage for you: https://support.signal.org/hc/articles/360007318471-Signal-Beta

Thank you. Quickly tested it, and now idle CPU is 0-2% with some random short 10% spikes. When writing a message the CPU consumption is around 10-17 % which is still pretty high. No spell checks etc. are enabled.

[jamiebuilds-signal]

Working on another change to improve the performance of typing further