Bug 419328

Summary: Canvas zooming framerate performance terrible when "brush presets" docker is open
Product: [Applications] krita Reporter: Ralek Kolemios <info>
Component: GeneralAssignee: Dmitry Kazakov <dimula73>
Status: RESOLVED FIXED    
Severity: normal CC: ahab.greybeard, dimula73
Priority: NOR    
Version First Reported In: nightly build (please specify the git hash!)   
Target Milestone: ---   
Platform: Microsoft Windows   
OS: Microsoft Windows   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:
Attachments: brush presets redraw framerate

Description Ralek Kolemios 2020-03-28 09:41:31 UTC
Within the last 4 or 5 builds, framerates when zooming have been performing absolutely terribly relative to a week ago. While I would normally get 110+ FPS when zooming, I am now getting on average 13 FPS on both OpenGL and Angle.
This doesn't affect rotating and panning, which still perform nicely at over 100FPS.
It's still present on an empty canvas, and a small resolution canvas.





Krita
  Version: 4.3.0-prealpha (git 902170c)

Qt
  Version (compiled): 5.12.7
  Version (loaded): 5.12.7

OS Information
  Build ABI: x86_64-little_endian-llp64
  Build CPU: x86_64
  CPU: x86_64
  Kernel Type: winnt
  Kernel Version: 10.0.17134
  Pretty Productname: Windows 10 (10.0)
  Product Type: windows
  Product Version: 10


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)" 
  Requested format:  QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::CompatibilityProfile) 
  Current format:    QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples 0, swapBehavior QSurfaceFormat::DefaultSwapBehavior, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::NoProfile) 
     Version: 3.0
     Supports deprecated functions false 
     is OpenGL ES: true 

QPA OpenGL Detection Info 
  supportsDesktopGL: true 
  supportsAngleD3D11: true 
  isQtPreferAngle: false 

Hardware Information
 Memory: 63 Gb
 Cores: 12
 Swap: C:/Windows/Temp
Comment 1 Ahab Greybeard 2020-04-02 15:30:20 UTC
This may have been fixed as a result of work on the following bug:
https://bugs.kde.org/show_bug.cgi?id=414576

Can you check this when the commit has been incorporated into the nightly build?
Comment 2 Ralek Kolemios 2020-04-03 15:40:18 UTC
cd1a423 nightly build's 4d7f346 commit does not seem to affect the zoom, still getting ~11 FPS when zooming. Have to revert to build 44d8e02 to get a smooth zoom again
Comment 3 Ralek Kolemios 2020-04-15 01:02:04 UTC
Since it hasn't been fixed yet and I'm stuck on an older build because of it, I looked further into the issue.
It seems to be worse on 4k screens, and the size of the viewport seems to be affecting it the most. When I resize the viewport to be much smaller, it runs a lot more like older builds (100+fps). But at standard resolution (About 2090x1850) it runs around 13FPS. This is most noticeable with drag-to-zoom with the pen.
It happens with nearest neighbor, and with high quality filtering. And with Texture buffer on and off.
Comment 4 Ralek Kolemios 2020-04-21 15:03:18 UTC
Looking further into it, the problem seems to be something related to these 2 commits, as the ones after that day (including the most recent nightly build) have a laggy smooth-zoom, and those before it seem to work fine.

https://github.com/KDE/krita/commit/e7cd22e0c3067009a1292e8b336c53aac589124b
https://github.com/KDE/krita/commit/f71d208167fc742284f3d65d96eb810979a56724

Or it could be any of the other commits that day, but these are the only ones related to zooming that changed in that build, and this build (nightly build for the 17th) as the first broken one.
Comment 5 Ralek Kolemios 2020-04-28 18:21:59 UTC
Created attachment 127956 [details]
brush presets redraw framerate

The longer I look into this the weirder it gets.
Removing the 'Brush Presets' Docker gets rid of the framerate issue entirely. And is a 'workaround' for now, though I have to re-open the brush presets docker each time I'd like to switch brushes.

Popping the docker out doesn't fix the issue, moving it to another monitor doesn't fix it either. However, popping it out does show the root of the problem- for some reason redrawing the brush presets window is very resource intensive, unlike other windows. For some reason, zooming in and out of the canvas forces a redraw of the brush preset box.

See attached for comparison between most windows and the brush presets window. Ignore offset mouse.
Comment 6 Dmitry Kazakov 2020-04-28 20:00:36 UTC
It looks like brush presets docker listens to the zooming signals and delays updates.
Comment 7 Dmitry Kazakov 2020-04-29 14:51:00 UTC
Git commit 06d70193e3a10d07b2ea09b354554d78bf4e4d70 by Dmitry Kazakov.
Committed on 29/04/2020 at 14:50.
Pushed by dkazakov into branch 'master'.

Don't update brush chooser on zoom change

Brush chooser should update itself only when the preset is changed.
Updating on zooming makes the zooming slow.

This bug is **not** present in krita/4.3

M  +7    -6    libs/ui/kis_paintop_box.cc
M  +28   -0    libs/ui/widgets/kis_preset_chooser.cpp
M  +4    -0    libs/ui/widgets/kis_preset_chooser.h
M  +10   -8    plugins/dockers/presetdocker/presetdocker_dock.cpp

https://invent.kde.org/kde/krita/commit/06d70193e3a10d07b2ea09b354554d78bf4e4d70