(macOS) High CPU Usage when scrolling in Playlist View on a high-DPI Retina Screen

[Tibokan]

Describe the bug
Probably a macOS, QT-specific issue (as it also exists on Clementine 1.3.1), but scrolling in Playlist View (even when not playing any tracks in the background) is very choppy in performance, with large CPU spikes and a tanking framerate (down to 8-10 frames on my high-spec Mac Pro, worse if glowing track animation is turned on, and there is a large list to scroll through). Scrolling the playlist view with a track playing will also tank the framerate of the block analyser.

To Reproduce
Add a list of songs to Playlist Views and scroll using mouse wheel.

Expected behavior
Scroll smoothly, as there shouldn't be anything CPU-heavy happening when scrolling a relatively static/non-dynamic playlist view.

System Information:

• Operating system: macOS 10.13.6
• Strawberry Version: 0.7.2.107

[Tibokan]

I wonder if it has anything to do with this QT bug report: https://bugreports.qt.io/plugins/servlet/mobile#issue/QTBUG-73117

[jonaski]

The playlist is actually a QTreeView (same as the collection), but they are both based on a QAbstractItemView, so yes it might be related.
I can't reproduce this problem in my VM but the screen size there is very small, so that might be the reason. The performance have actually been very good recently, not sure if it happened after I upgraded to Qt 5.15.1, but it's never been this good, there is no choppy scrolling of the playlist at all. Until recently everything was choppy and laggy for me on macOS.

[Tibokan]

Making the window really small improves the scrolling performance a fair bit, though there is still a noticeable hit to performance (I use an app called iStat Menus that has a frames monitor, which allows me to see the hit to number of rendered frames when scrolling - drops to 6-12 at full screen, 1680x1050, when window is very small, 18-20 (close to the magic 25 for smoothness)

[Tibokan]

The collection view also has impacted scrolling performance, but I think because its such a finite list, both column and size wise, the noticeability of the performance impact is minimal there.

Is there an alternate way of doing the collection and playlist view on MacOS that might alleviate this issue?

[llucps]

Hi.

Are you using a HDPI screen? (aka retina) I've noticed a big difference in performance when using Strawberry with the retina display from my Macbook Pro and when connected to external displays (22" 1920x1080px) and 25(2560 x 1440px) it works way better. this on Mac OS Catalina, but I don't think the macos version matters.

I would guess the performance is because the QT implementation on macOS..

Is there any improvement on QT 6 @jonaski ?

Thanks.

[jonaski]

Try turn off the background image and the "source" column to see if that makes any difference.
But there is so much stuff going on so it's hard to tell without running some sort of profiling to see what uses most resources. But it does not do anything specific to macOS in the playlist view, so the most likely reason is a Qt-macOS problem.
On macOS there is a program called "instruments", I think you need to install xcode for it to be available. I have never used it before. I think it should reveal what is going on.
There is a tutorial here: https://developer.apple.com/videos/play/wwdc2019/411/

[Tibokan]

@llucps it's a standard Samsung 24 inch IPS monitor that I have my Mac Pro plugged into, not an Apple Retina display. I noticed that playing around with the resolutions will make this problem better or worse - lower resolutions will improve frame performance (similar to the way making the Strawberry window smaller improves performance), and higher resolutions (I can go up to 1920x1080) reduces frame performance. I can imagine it being even worse on a Retina display, as the standard resolutions on that are 2560×1600 and above.

Background image doesn't seem to be related to this issue, as there is the same performance impact on scroll with it on or off. I have also tested with source column on/off with no difference (I typically have that column off by default anyway).

It feels like something is happening in the background when scrolling these views, probably the multiple, unnecessary repaints mentioned in that bug report. Since it's unresolved in QT5, not sure if there is much @jonaski can do to fix this performance issue unless there's an alternate way of doing the views, though hopefully it will get fixed in QT6.

I will have a go with instruments to uncover more information once I get some free time later this week.

[jonaski]

If you can figure out instruments I think that would really help it get fixed even if the bug is in Qt.
I have only tested with Qt 6 on Linux so far, but my initial impression is that there is a performance increase. I actually use strawberry compiled with Qt 6 on daily basis already on Linux, everything seem to be working fine.
Final release of Qt 6 is just a few months away, November I think, and homebrew is pretty quick to update packages, so then I will probably be able to switch to Qt 6 pretty fast for macOS and windows builds.

[Tibokan]

Struggling to get hold of Xcode at the moment, with Apple's stringent latest OS requirements (Catalina) on Xcode and the fact I haven't added it to my Mac account in the past, meaning that I am having to delve into the Apple archives to try and find a compatible Xcode version to suit High Sierra (which looks like it tops out at Xcode 10.1). So far, everything I have downloaded has failed to extract and install.

I will gain access to a Catalina-based Apple machine within the next week, so should be able to get Xcode attached to my Mac account and get hold of the latest version to do some testing using Instruments.

On a side note, having used Strawberry a fair bit over the past week on my less powerful 2014 MacBook Pro (which has a far less powerful CPU in it compared to my 2013 Mac Pro), the scrolling performance is noticeably choppier, so it seems CPU specs plays a part in how noticeable this scrolling issue is.

Hopefully QT6 will solve the issue altogether, though I will still try and get some Instruments info and reports back to you in the meantime.

[Tibokan]

Would it be possible to add a beta QT6 build of Strawberry for MacOS to the Latest Builds section?

[jonaski]

Yes but it is a bit work to set up compiling Qt 6 dev branch for mac.

[Tibokan]

I have now gotten Xcode working, and have had a play with Instruments - this is on a Catalina-based iMac.

I ran a couple of traces on Strawberry using the Animation Hitches tool:

Whilst scrolling, it does appear there are multiple CPU calls every split second, which is probably what is tanking the frame rate and scrolling performance:

Here's a detailed trace on Strawberry and the primary CPU offenders:

I'm not sure if the above screenshots tell you much (outside of this definitely being CPU-related and focused around QPainter), so if there is another Instruments tool and output that would be more informative for you in diagnosing this issue, please let me know.

[Tibokan]

This link seems to talk about the same issue identified in the screenshots above regarding the QPainter DrawImage on MacOS impacting performance and it details a potential workaround to consider:
https://forum.qt.io/topic/84262/mac-os-repainting-parented-widget-performance-seem-to-depend-on-ancestors-chain

[jonaski]

Pretty sure this is in Qt and not really much we can do to improve the performance in Strawberry, it shows QMainWindow::event() which we do not re-implement.

[jonaski]

Closing this as it doesn't seem to be resolvable.

[Tibokan]

I think this should be reopened now that QT6 has been released, as it's a big problem for Strawberry on any Mac's with a high-DPI Retina Screen (pretty much everyone outside of those using MacOS on Hackintoshs). High-end specs don't help either, as my second-to-top 2020 iMac with the i7 gets 100% CPU usage and Strawberry is heavily laggy, and I'm forced to keep Strawberry playing in the background minimised, or make the Strawberry window very small, to avoid having other tasks impacted.

[Tibokan]

Thanks for reopening, are there any working QT6 Strawberry builds available for Catalina that I can start testing with/reporting results on? The one I was able to find in the forums/download repository crashes on launch currently

[jonaski]

I switched to Qt 6 now. 0.8.5.131 and newer are Qt 6 and working: https://builds.strawberrymusicplayer.org/macos

[Tibokan]

Thanks Jonas, I have downloaded and done some initial testing using 0.8.5.136. The good news is that Strawberry graphics performance has improved slightly compared to QT5. The bad news is that the scrolling smoothness/graphics performance on the playlist view is still noticeably laggy/CPU heavy (which then causes stuff like the Block Analyser to freeze in place/stop moving briefly when scrolling). The previous trick of making the Strawberry window really small makes the scrolling performance buttery smooth, so it seems the graphics performance/CPU usage bug that is hindering the Playlist view/scroll has flowed over from QT5 to QT6 :(

[jonaski]

It's not really surprising, the main changes in Qt 6 are in Core, not Gui/Widgets, and if there was a bug fixed, it would probably have been fixed in 5.15.2 too.

[Tibokan]

Did some research on the QTreeView performance issue - I found a potential solution to improving performance (https://stackoverflow.com/questions/19691577/qtableview-slow-performance-with-1000s-of-visible-cells) - the suggestion is to set the setUniformRowHeights flag to True (it is by default false). I’m not sure if this has already been implemented in Strawberry, it might be worth a shot if not

[jonaski]

I can try setting that, however when looking into the playlist view code I found the following code that is unique to macOS:
setVerticalScrollMode(QAbstractItemView::ScrollPerPixel);
Maybe that's what's causing it, I see it was done in 2010 here: clementine-player/Clementine@71bfbd9#diff-ddf6206a2958cd2c20232febf2177177929323c3a225746391a126e3a4830b4e
It's possible that this isn't required anymore, so worth to try removing that first.

[Tibokan]

I think that was added to avoid per-line scrolling - are the non-MacOS Strawberry builds scrolling on a per line basis and feel smooth/perform well?

If so, it’s probably the solution for this issue on MacOS, though it’s still strange why scrollbypixel mode would be causing such a performance impact unless there was a change in scroll implementation between QT versions 4 and 5. Maybe the high pixel count of today’s retina screens/resolution is placing too much of a load on this QT function compared to the lower resolutions/screens that would have been commonly used back in 2010?

[jonaski]

I think so.
I made some builds with the modifications available now on https://builds.strawberrymusicplayer.org/macos/ as strawberry-playlistviewmod
I removed setVerticalScrollMode and added setUniformRowHeights.
Can you test and see if it helps?

[jonaski]

I found that the cover manager crashes on macOS the second time it is opened.
It is related to the native search field. This should fix it f5bb15f
It would be nice if you can test too.

[Tibokan]

I think so.
I made some builds with the modifications available now on https://builds.strawberrymusicplayer.org/macos/ as strawberry-playlistviewmod
I removed setVerticalScrollMode and added setUniformRowHeights.
Can you test and see if it helps?

I've done some testing over the last few hours with the playlistviewmod dev build, and unfortunately it does not seem to have made any impact/change at all. The scrolling still appears to be by pixel (rather than by row as we had anticipated) and the performance has not been improved despite the presence of setUniformRowHeights. The performance, as before, improves when the playlist window is made very small. I'm guessing there is code somewhere that is still forcing the scrolling by pixel in Playlist View, regardless of that line of code from PlaylistView.cpp being removed?

I found that the cover manager crashes on macOS the second time it is opened.
It is related to the native search field. This should fix it f5bb15f
It would be nice if you can test too.

I'll do some testing once it flows through to the latest builds and report back

[jonaski]

It's possible to experiment with a custom playlist view delegate to see if it can be optimized.

[llucps]

Thanks @jonaski. Happy to help testing.

[Tibokan]

https://codereview.qt-project.org/c/qt/qtbase/+/353233
Looks like the QT team has confirmed that there is a bug with the scroll optimisation on both Mac and Windows, hopefully a fix will be incoming in the near future that will solve this problem once and for all

[foss-]

For reference: QTBUG-73117 and https://codereview.qt-project.org/c/qt/qtbase/+/373409 (merged 2022-01-13) is seeing some action.

[Tibokan]

Looks like this has now been fixed (as foss indicates, it was committed to the QT build in January), so this bug should now be solved once the builds are updated to compile using the latest QT 6.2.3 (or the upcoming QT 6.3) instead of the current QT 6.2.2 which doesn't contain this bug fix.

[jonaski]

I know. It took homebrew over a month to upgrade to qt 6.2.3 so it just missed the latest strawberry release.
But I have been working on building all dependencies for macOS myself so I don't have to rely on homebrew anymore. There are other problems with using homebrew, such as the gstreamer installation being incomplete, and they refuse to build the missing plugins I need.
I have just finished building everything here: https://github.com/strawberrymusicplayer/strawberry-macos-dependencies
I'm just working on switching the strawberry github actions use the new dependencies instead of homebrew. I will let you know once that's finished and you can test.

[jonaski]

Ready now on https://builds.strawberrymusicplayer.org/macos/
1.0.2.22 and newer are the new ones.

[llucps]

Thank you very much @jonaski , this is great news!

One thing though, since I have an Mac mini M1, I've been compiling Strawberry using MacPorts myself. I gueds I'll have to wait until the currently qt 6.2.1 gets update, so the fix fixed gets applied. correct?

I'll try the new build with my old Macbook Pro 2013 which is retina display, and see if makes a difference.

Thanks!

[foss-]

Version 1.0.2-8-gd40a67ce, scrolling playlist like mad -> CPU over 90%
Version 1.0.2-28-g8557d835, scrolling playlist like mad -> CPU at 99%

Sadly cannot confirm a fix for high CPU usage when scrolling.

[foss-]

Version 1.0.4 scrolling up down still goes to ~99% CPU

[jonaski]

Can you try the latest from https://builds.strawberrymusicplayer.org/macos/ those have Qt 6.3.0 (instead of Qt 6.2.x).

[foss-]

macOS 12.3.1
Strawberry 1.0.4-5-g907dfee6
Scrolling up down like crazy still results in CPU ~100%.
https://bugreports.qt.io/browse/QTBUG-73117 however still unresolved and with last update early dec 2021.

[jonaski]

QTBUG-73117 is closed and the latest fix was https://codereview.qt-project.org/c/qt/qtbase/+/403699 which should be in Qt 6.3.0.
I doubt we will get this fixed in Strawberry unless someone with a mac volunteers to debug it and report it to Qt with a minimal code example that can reproduce it. Since there aren't any contributors here with mac, I doubt we will get this fixed any time soon.

[jonaski]

Since I got a Mac Mini M2 now I've tested with a Samsung UHD TV on resolution 3840 x 2160, I can reproduce high CPU usage when scrolling.

[jonaski]

I'm pretty sure this is a Qt specific issue, lyx (https://www.lyx.org/Download) also exhibit the same behavior, over 60% CPU when scrolling.

[jonaski]

I've reported this to Qt here: https://bugreports.qt.io/browse/QTBUG-123343