https://bugs.kde.org/show_bug.cgi?id=390041
--- Comment #4 from Alvin Wong <alvinhoc...@gmail.com> --- 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.
