[7.5.0RC6] Channels screen uses 75% CPU

[synctext]

Installed RC6 on Ubuntu 18.04 LTS.
When running Tribler idle for 7 hours it uses 5 hours and 11 minutes of CPU time.
The "discovered" screen seems to use a lot of CPU when refreshing. Discovered 1957 channels and subscribed to 26 channels. 4.4G Jun 15 17:19 metadata.db.

Dramatic drop in CPU when moving away. The laptop fan turns off when switching to the "Downloads" screen, reproducible. Note that the CPU usage debug panel graph in Tribler itself is not accurate, it misses the CPU usage. Not a showstopper, but hopefully something we can fix without too much efforts.

btw To discuss: this is the sort of manual testing I hope we can Devops / automate in the coming months with a single Dashboard approach.

[ichorid]

I always knew the way I implemented the "waiting" animation is gonna bite us in the back... It was not that bad until a lot of channels were added.
Replaced the animation with a static picture in #5378. Though if you just move your mouse around the channels list, your CPU will spike because of unnecessary redraws. Still have to optimize that.

[synctext]

OK, thank you for that insight. Removing the spinning animation really degrades the experience that Tribler is working hard for you. Let's think..

[synctext]

self.share_icon.paint(painter, self.get_indicator_rect(option.rect))

btw Is there animated .GIF support that uses less CPU?

[ichorid]

AFAIK, that's not trivial, especially with custom-drawn table delegates. There is no light-weight support for icon animations in QT. The corresponding Stack page describes the simplest solution that connects the animation redraw signal to redraw the whole table along with more sophisticated ones. To solve this, I'll have to try 3-5 different methods and it is entirely possible that this can't be solved without going to higher-lever APIs like QML, or going lower with e.g. platform-specific API calls, etc.

For now, I would just disable the animation completely.