Bug 440951

Summary:	Scrolling and browsing brush preset spikes CPU core usage and lag occurs making it hard to use the docker
Product:	[Applications] krita	Reporter:	Raghavendra kamath <raghu>
Component:	Dockers	Assignee:	Lynx3d <lynx.mw+kde>
Status:	RESOLVED FIXED
Severity:	normal	CC:	ahab.greybeard, lynx.mw+kde
Priority:	NOR
Version First Reported In:	nightly build (please specify the git hash!)
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:	https://invent.kde.org/graphics/krita/commit/1fb0eb8ce1d94869a6ebdf87e83e53081f303914	Version Fixed/Implemented In:
Sentry Crash Report:

Description Raghavendra kamath 2021-08-14 07:57:21 UTC

SUMMARY
In the latest nightly build (git e89467b) appimage scrolling the brush preset docker is lagging. scroll operation spikes 1 cpu core to 100 and if the docker is undocked it even becomes difficult to move it quickly. Dropdown appears very late. Brush selection is done very late. 

I also see as we scroll the status bar switches to shows the brush preset name only hiding all other text in the place of currently active brush name.



STEPS TO REPRODUCE
1. Open the nightly build of 14 august 2021 and open the brush preset docker.
2. Scroll through the list of thumbnails, undock the docker and open the dropdown etc


I noticed the lag is slightly less when using the list view.

Comment 1 Raghavendra kamath 2021-08-14 08:00:53 UTC

The dropdown brush preset chooser is also affected by this

Comment 2 Lynx3d 2021-08-14 20:10:12 UTC

Oh wow..."is lagging" is a gross understatement here, the further I scroll down my preset list the longer Krita freezes, I stopped after reaching around 30 seconds for one more wheel "tick", and wasn't even at half down list O.O

Comment 3 Halla Rempt 2021-08-16 08:20:26 UTC

Git commit 1fb0eb8ce1d94869a6ebdf87e83e53081f303914 by Halla Rempt, on behalf of Mathias Wein.
Committed on 16/08/2021 at 08:20.
Pushed by rempt into branch 'master'.

Don't search for occurrence of empty strings in resourceExists()

For filename there exists an automatic index due to the table condition:
UNIQUE("storage_id","resource_type_id","filename")
so the search is fast, and should solve Bug 440951.

But the search for md5 is about 2 orders of magnitude on a
resource collection with a few additional packs.
It's not clear yet why searching for name isn't nearly as slow,
despite also lacking an (auto-)index, according to the
"EXPLAIN QUERY PLAN" output.

M  +50   -40   libs/resources/KisResourceModel.cpp

https://invent.kde.org/graphics/krita/commit/1fb0eb8ce1d94869a6ebdf87e83e53081f303914

Comment 4 Ahab Greybeard 2021-08-16 17:51:24 UTC

*** Bug 441041 has been marked as a duplicate of this bug. ***