When drawing on a large canvas, the appearance of a stroke is delayed momentarily every so often. For me this occurs approximately one and a half seconds after the previous stroke, and the problem can be sustained by drawing a new stroke every 1.5 seconds thereafter. Confirmed in Krita 3.0.1.90, Windows 10 on both an 8 year old desktop and a Surface Pro 4. Reproducible: Always Steps to Reproduce: 1. Create a new 7000 x 4000 image 2. Select any brush and draw a series of short strokes, gradually increasing the time between strokes until there is a delay. Note: I think this was either reported or mentioned somewhere in a previous report, but unfortunately I was unable to locate that report, so apologies if this is a duplicate.
Does this also happen with instant preview enabled or disabled?
Happens whether it's enabled or not. Strangely, I just opened the Advanced Colour Selector docker, and the problem went away until I closed it again. I tried opening it again and the problem was still there though, so I'm not sure what that was about. Does that offer any clues?
Yes... Though it's still strange that this doesn't happen to me, but it suggests a place to start looking.
you don't have stabilizer or another smooth option active per mistake? I would assume not,as advanced color selector has nothing to do with that,but it might be something to eleminate first,and be absolutely sure
No stabilizer, only basic smoothing is on, although none of the smoothing options seem to make any difference. Also I haven't been able to repeat the Advanced Colour Selector incident so far.
I forgot to add that this problem resurfaced in the first 3.1 beta (3.0.99.90), so I'm still using 3.0-9e17aff since that's the most recent build that doesn't exhibit the problem. I don't recall when it initially cropped up (it might have been in the switch from 2.9 to 3.0) and then was subsequently fixed, but I'll try and locate those versions if that would help in tracking down the issue.
Does it matter whether opengl or angle are enabled, or when cpu rendering is used?
Desktop: With OpenGL the problem is less pronounced than it used to be; the strokes are drawn in small chunks instead of fluidly with a timing of roughly 0.7 seconds between strokes, gets slightly worse as the timing is increased, and goes back to being fluid at around 1.5 seconds between strokes. Angle gives very similar results. With CPU rendering, strokes are drawn in a consistently choppy fashion regardless of the timing between strokes. Surface Pro 4: OpenGL and Angle both behave like CPU rendering does on the desktop (i.e. a bit choppy), and it doesn't look like changing timing between strokes is having any adverse affect. CPU rendering is consistently fluid no matter the timing.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!
Requested info was provided in Comment 8. Revisiting this issue in Krita 4.2.0, I find that on the desktop the latency is at its worst when strokes are spaced apart by about 1 second, whereas it is more sporadic and less frequent on the SP4. Also I tested a more recent GPU (GTX 660) in the desktop, and the issue was not improved at all.
@Chris Jones, does bug 421376 sound similar? Do you think it's the same issue?
.
(In reply to Tymond from comment #13) > . I think this might be a different issue, since the pauses only occur at the start of new strokes rather than mid-stroke. Also it happens regardless of the amount of RAM that's being used. Incidentally I still have this problem in 4.3.0.
Thanks for your comment! Automatically switching the status of this bug to REPORTED so that the KDE team knows that the bug is ready to get confirmed. In the future you may also do this yourself when providing needed information.
@chrisjones incidently is it possible this issue occurs after using undo?
(In reply to Bollebib from comment #16) > @chrisjones > > incidently is it possible this issue occurs after using undo? It happens regardless of whether there has been any undo. Also I noticed it starts happening less than a second after the initial stroke now (instead of the 1.5 seconds originally reported), and can occur any time after that stroke. Usually I get immediate strokes as long as they're within around half a second of the previous one.
I can't notice the delay on the Surface Pro 4 now though.