Bug 390041 - Ruler cause slow canvas performance in high zoom level
Summary: Ruler cause slow canvas performance in high zoom level
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Usability (show other bugs)
Version: git master (please specify the git hash!)
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-02-07 20:02 UTC by Alvin Wong
Modified: 2018-02-17 17:42 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Paint Analyzer in GammaRay (210.80 KB, image/png)
2018-02-12 19:23 UTC, Alvin Wong
Details
GammaRay shows ruler painting with 4.0 beta 1 (479.93 KB, image/png)
2018-02-16 04:50 UTC, Alvin Wong
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alvin Wong 2018-02-07 20:02:15 UTC
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?)
Comment 1 Alvin Wong 2018-02-12 19:23:21 UTC
Created attachment 110574 [details]
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.
Comment 2 Halla Rempt 2018-02-13 08:13:30 UTC
Right... I didn't know gammaray could do this :-)
Comment 3 simeirxh 2018-02-16 02:22:26 UTC
(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.
Comment 4 Alvin Wong 2018-02-16 04:49:00 UTC
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.
Comment 5 Alvin Wong 2018-02-16 04:50:36 UTC
Created attachment 110700 [details]
GammaRay shows ruler painting with 4.0 beta 1

The image here is still 3600px wide
Comment 6 simeirxh 2018-02-16 09:47:42 UTC
(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.
Comment 7 Alvin Wong 2018-02-17 17:42:48 UTC
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   -4    libs/widgets/KoRuler.cpp

https://commits.kde.org/krita/1521ea858cb247662001e08e9995efb134e8da89