Bug 423768 - Brush presets docker being too large affects performance of brush rendering and UI.
Summary: Brush presets docker being too large affects performance of brush rendering a...
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Dockers (show other bugs)
Version: nightly build (please specify the git hash!)
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-07-01 20:58 UTC by Ralek Kolemios
Modified: 2021-02-27 17:04 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ralek Kolemios 2020-07-01 20:58:03 UTC
If the brush presets docker is too large, it can slow down the rendering of other aspects of the program.

For instance, drawing any line with any brush engine with either the mouse or pen will delay the rendering of the stroke anywhere between 20 and 100ms. This can be jarring for drawing.

It's worth it to note this delay in rendering only occurs if any brush preset is highlighted in the brush presets docker. If the program is recently opened and no preset is selected, canvas rendering is as expected.

The brush preset docker's size also affects the overall UI performance, slowing the rest of the UI down to as low as 15 fps.



Krita
  Version: 5.0.0-prealpha (git 8dccf4f)
Qt
  Version (compiled): 5.12.8
  Version (loaded): 5.12.8
OS Information
  Build ABI: x86_64-little_endian-llp64
  Pretty Productname: Windows 10 (10.0)
OpenGL Info
  Vendor:  "Google Inc." 
  Renderer:  "ANGLE (NVIDIA GeForce GTX 980 Ti Direct3D11 vs_5_0 ps_5_0)" 
  Version:  "OpenGL ES 3.0 (ANGLE 2.1.0.57ea533f79a7)" 
  Shading language:  "OpenGL ES GLSL ES 3.00 (ANGLE 2.1.0.57ea533f79a7)" 
QPA OpenGL Detection Info 
  supportsDesktopGL: true 
  supportsAngleD3D11: true 
  isQtPreferAngle: true 
Hardware Information
 Memory: 63 Gb
 Cores: 12
 Swap: C:/Windows/Temp
Comment 1 Ahab Greybeard 2020-07-03 13:17:05 UTC
I don't see that with the 5.0.0 prealpha (git gcbceee) .zip package on Windows 10.

With a 4096 x 4096 canvas and a large Brush Presets docker showing many icons, I get rapid response and fps of about 100 with very fast brush strokes.
I've tried it with OpenGL and with Angle.
Some complicated colour smudge engine brushes are slow, but not many.
Comment 2 Ralek Kolemios 2020-07-04 02:32:51 UTC
Just measured with a high speed camera, there is a ~200ms delay between first pen touch and the first frame of drawing. After this delay, the brush returns to its usual 100+ FPS

This delay doesn't exist when the brush presets docker is either hidden, small, or there is no brush preset selected. 
Win 10 cbceee2 zip
Since this doesn't seem to be reproducible elsewhere so far, what would be the next steps for me to trace the issue on my end?
Comment 3 Ralek Kolemios 2020-08-04 21:28:28 UTC
Can confirm sketching is still impossible while the brush presets docker is open in windows zip package git 929466a
Comment 4 Ralek Kolemios 2020-08-04 21:49:55 UTC
After some more rigorous testing, it seems to be affected by which bundles I currently have loaded.

-Having only the basic Krita 4 bundle activated results in smooth drawing.
-Having only 'local' brushes activated will cause a heavy delay when drawing.
-Having 'local' deactivated, the Krita 4 bundle deactivated, and just my own bundles activated crashed my Krita.
-Having 'local' activated, my bundles activated, and the basic Krita 4 bundle activated seemed to work fine, despite there being significantly more brush presets in the docker.

Quite frankly I don't know what could be going on, but I assume it's heavily dependent on the resources rework, so I'll keep an eye on the issue going forward. Or if you had some more tests you'd have me do or anything else I can help with, let me know.
Comment 5 Halla Rempt 2021-02-13 14:00:08 UTC
Maybe this is now gone with https://invent.kde.org/graphics/krita/-/merge_requests/696 being merged?
Comment 6 Ralek Kolemios 2021-02-27 16:59:27 UTC
As far as I can tell, this is no longer an issue in the latest nightly builds.
Comment 7 Halla Rempt 2021-02-27 17:04:13 UTC
Thanks for checking! It's Sharaf's work that fixed it :-)