Bug 436243 - Scrolling notification history is 0.3 FPS
Summary: Scrolling notification history is 0.3 FPS
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Notifications (show other bugs)
Version: 5.21.4
Platform: openSUSE Linux
: NOR normal
Target Milestone: 1.0
Assignee: Kai Uwe Broulik
URL:
Keywords: efficiency-and-performance
Depends on:
Blocks:
 
Reported: 2021-04-26 21:08 UTC by Ilya Bizyaev
Modified: 2023-04-28 04:08 UTC (History)
5 users (show)

See Also:
Latest Commit: https://invent.kde.org/plasma/plasma-workspace/-/commit/37bf7e5d73f03b258bd7bf57ae87d95f72fb2a59
Version Fixed In: 5.27
Sentry Crash Report:

Attachments
Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description Ilya Bizyaev 2021-04-26 21:08:08 UTC 
SUMMARY
When I have a sizable notification history, scrolling it takes around 3 seconds to render next frame and is thus too jumpy to be usable.

STEPS TO REPRODUCE
1. Receive a bunch of notifications
2. Open the Notifications plasmoid
3. Try scrolling (touchpad here)


SOFTWARE/OS VERSIONS
Operating System: openSUSE Leap 15.2
KDE Plasma Version: 5.21.4
KDE Frameworks Version: 5.81.0
Qt Version: 5.15.2
Graphics Platform: X11
Processors: 8 × Intel® Core™ i5-10210U CPU @ 1.60GHz
Graphics Processor: Mesa DRI Intel® UHD Graphics
Comment 1 Nate Graham 2021-04-27 19:40:47 UTC 
yikes

What counts as a bunch? 50? 500? 5000?
Comment 2 Ilya Bizyaev 2021-04-27 19:41:37 UTC 
Oh, I later counted, and it was 99 :)
Comment 3 Patrick Silva 2021-05-31 02:43:13 UTC 
I have noticed this problem on Wayland session of neon unstable.
Comment 4 Laura David Hurka 2021-06-20 20:46:25 UTC 
Same here. I installed NeoChat yesterday to join Akademy, and not about 1000 messages. Today I looked in my notifications, and had only 0.3 or 0.1 FPS when scrolling, and deleting only the top-most notification froze my computer for about 10 seconds. After some time, I discovered that NeoChat created one notification for each of the 1000 messages, so that is probably why.

Are notifications stored in a QVector or so, where deleting the first one 1000 times causes 500,000 memory reallocations or so?

SOFTWARE/OS VERSIONS
Comment 5 Laura David Hurka 2021-06-20 20:46:44 UTC 
SOFTWARE/OS VERSIONS
Operating System: KDE neon 5.22
KDE Plasma Version: 5.22.1
KDE Frameworks Version: 5.83.0
Qt Version: 5.15.3
Kernel Version: 5.4.0-74-generic (64-bit)
Graphics Platform: X11
Processors: 4 × Intel® Core™ i5-4300U CPU @ 1.90GHz
Memory: 7.5 GiB of RAM
Graphics Processor: Mesa DRI Intel® HD Graphics 4400
Comment 6 Fushan Wen 2021-12-01 14:10:14 UTC 
Can reproduce. ListView is of little use.
Comment 7 Kai Uwe Broulik 2021-12-01 14:12:30 UTC 
They are stored in a QVector, yes. However I believe the bottleneck to be the grouping proxy model
Comment 8 Nate Graham 2022-01-07 14:09:15 UTC 
This has been fixed by Carl Schwan with https://invent.kde.org/plasma/plasma-workspace/-/commit/37bf7e5d73f03b258bd7bf57ae87d95f72fb2a59 in Plasma 5.24
Comment 9 Patrick Silva 2022-05-23 14:13:34 UTC 
The scrolling is still very slow on Wayland when I have many notifications from Spectacle in the history.

Operating System: KDE neon Unstable Edition
KDE Plasma Version: 5.25.80
KDE Frameworks Version: 5.95.0
Qt Version: 5.15.4
Graphics Platform: Wayland
Comment 10 Kai Uwe Broulik 2022-09-10 21:07:42 UTC 
reuseItems on ListView could help but that would need some refactoring since we have a Loader to decide between app section and notification and so it would still create/destroy a whole bunch of items as we scrolled
Comment 11 Bug Janitor Service 2022-11-03 15:45:00 UTC 
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2298
Comment 12 Nate Graham 2023-04-28 04:08:02 UTC 
Should be fully fixed in Plasma 5.27.