[krita] [Bug 390041] Ruler cause slow canvas performance in high zoom level
https://bugs.kde.org/show_bug.cgi?id=390041 Alvin Wong changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED Latest Commit||https://commits.kde.org/kri ||ta/1521ea858cb247662001e08e ||9995efb134e8da89 --- Comment #7 from Alvin Wong --- Git commit 1521ea858cb247662001e08e9995efb134e8da89 by Alvin Wong, on behalf of Michael Zhou. Committed on 17/02/2018 at 17:41. Pushed by alvinwong into branch 'master'. Fix ruler performance problem The ruler used to draw the marks no matter if they are visible. This causes a performance problem as under high zoom levels, a large number (equals to or more than the number of pixels along the width or height of the canvas) of marks will be drawn. This patch changes the behavior, let the ruler draw only the marks that are visible or partially visible. Regression from ba60778bd55071449c56acd78c056623ce7e7ac6 Differential Revision: https://phabricator.kde.org/D10572 M +50 -4libs/widgets/KoRuler.cpp https://commits.kde.org/krita/1521ea858cb247662001e08e9995efb134e8da89 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 390041] Ruler cause slow canvas performance in high zoom level
https://bugs.kde.org/show_bug.cgi?id=390041 --- Comment #6 from simei...@gmail.com --- (In reply to Alvin Wong from comment #5) > Created attachment 110700 [details] > GammaRay shows ruler painting with 4.0 beta 1 > > The image here is still 3600px wide Alvin, You are correct. Though I don't want to admit it, it is my commit that causes the problem... I create a new patch on https://phabricator.kde.org/D10572. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 390041] Ruler cause slow canvas performance in high zoom level
https://bugs.kde.org/show_bug.cgi?id=390041 --- Comment #5 from Alvin Wong --- Created attachment 110700 --> https://bugs.kde.org/attachment.cgi?id=110700&action=edit GammaRay shows ruler painting with 4.0 beta 1 The image here is still 3600px wide -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 390041] Ruler cause slow canvas performance in high zoom level
https://bugs.kde.org/show_bug.cgi?id=390041 --- Comment #4 from Alvin Wong --- Hi Michael, This isn't exactly what I observed though. Yes, the ruler being a little bit larger than the canvas does seem to exist before your change, but it definitely is a bug. I would have expected you to have fixed it since you did rewrite a huge part of the code, oh well. The behaviour of painting the marks outside of the visible range does not exist on 4.0 beta 1. I checked it with GammaRay just now (I'll attach a screenshot of it). And it definitely does affect the performance. It depends on the size of the image: In the screenshot from comment #1, the image width is 3600px, and the visible ruler range is 1722-1741 which consists of 20 marks, so only 0.556% of the marks are visible. The cost of painting the text of each invisible mark is around 0.02% to 0.03% which makes the percentage of time wasted in painting the invisible marks to be about 0.02% * (3604-20) = 71.68%. For me it causes the canvas fps to drop significantly when panning (compared to having the ruler invisible). You can test with the nightly build. The latest Windows nightly build can be found here: https://binary-factory.kde.org/job/Krita_Nightly_Build/ It would be great if you can check it soon. (While you are at it, there are also some undesirable behaviours: (1.) At a certain zoom level, the subdivision marks aren't aligned to the pixel boundaries. (2.) At high zoom levels, the subdivision marks reaches subpixel-level which seems a bit unnecessary.) (In reply to simeirxh from comment #3) > The behavior of the ruler to be a little larger than the canvas and to paint > all marks no matter if they are visible existed before my commit you > mentioned. They exist in both 3.3.3 (it's the newest stable release, right?) > and master, which are both having their rulers working normally. It's true > that they are not working completely in the expected way (I feel that they > are strange, too when I was reading the code), but the unexpected behaviors > doesn't actually affect usage, right? The extra pixels hardly make any > difficulties in painting, and the extra painted marks are not visible > because they are out of the range of the widget. I suppose that's why the > original programmer left them there... Therefore, I don't think either my > commit or the behaviors you mentioned caused the bug. I don't know how the > nightly packages work. If you can tell me that, then I think I might be able > to go back to the ruler class and see if I can do something, on both the bug > and the strange behaviors. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 390041] Ruler cause slow canvas performance in high zoom level
https://bugs.kde.org/show_bug.cgi?id=390041 --- Comment #3 from simei...@gmail.com --- (In reply to Alvin Wong from comment #0) > Panning the canvas is noticeable slower with ruler enabled when under high > zoom level (> 1000%). > > Found in krita-nightly-x64-v4.0.0.51-222-g34bb24e195, not on beta 1. I > suspected the commit > https://phabricator.kde.org/R37:ba60778bd55071449c56acd78c056623ce7e7ac6 to > have introduced the regression, confirmation needed. > > CC: Michael Zhou (I think the email should be right?) Hi Alvin, Sorry for the late reply. The behavior of the ruler to be a little larger than the canvas and to paint all marks no matter if they are visible existed before my commit you mentioned. They exist in both 3.3.3 (it's the newest stable release, right?) and master, which are both having their rulers working normally. It's true that they are not working completely in the expected way (I feel that they are strange, too when I was reading the code), but the unexpected behaviors doesn't actually affect usage, right? The extra pixels hardly make any difficulties in painting, and the extra painted marks are not visible because they are out of the range of the widget. I suppose that's why the original programmer left them there... Therefore, I don't think either my commit or the behaviors you mentioned caused the bug. I don't know how the nightly packages work. If you can tell me that, then I think I might be able to go back to the ruler class and see if I can do something, on both the bug and the strange behaviors. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 390041] Ruler cause slow canvas performance in high zoom level
https://bugs.kde.org/show_bug.cgi?id=390041 Boudewijn Rempt changed: What|Removed |Added CC||b...@valdyas.org Status|UNCONFIRMED |CONFIRMED Ever confirmed|0 |1 --- Comment #2 from Boudewijn Rempt --- Right... I didn't know gammaray could do this :-) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 390041] Ruler cause slow canvas performance in high zoom level
https://bugs.kde.org/show_bug.cgi?id=390041 --- Comment #1 from Alvin Wong --- Created attachment 110574 --> https://bugs.kde.org/attachment.cgi?id=110574&action=edit Paint Analyzer in GammaRay I suspected (without reading the code clearly) that the new ruler painting code tries to paint all the ruler marks, as opposed to only the visible ones... So I checked with GammaRay, and it does look like the ruler is trying to paint all the marks, starting from 0, and even all the way to 3604 even when the image is only 3600px wide. Setting to confirmed because the behaviour is definitely not right. -- You are receiving this mail because: You are watching all bug changes.
