Bug 409460 - Canvas pan & zoom frame 'spacing' inconsistent
Summary: Canvas pan & zoom frame 'spacing' inconsistent
Status: RESOLVED MOVED
Alias: None
Product: krita
Classification: Applications
Component: OpenGL Canvas (show other bugs)
Version: nightly build (please specify the git hash!)
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Dmitry Kazakov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-07-03 13:42 UTC by Ralek Kolemios
Modified: 2021-06-24 09:33 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
High speed footage of the rendering issue (448.01 KB, video/webm)
2019-07-03 13:42 UTC, Ralek Kolemios
Details
Emulated example of rendering issue (404.94 KB, image/gif)
2019-07-04 01:11 UTC, Ralek Kolemios
Details
DebugView logs (600.40 KB, text/plain)
2019-07-08 19:44 UTC, Ralek Kolemios
Details
New package slow motion (487.50 KB, video/webm)
2019-07-08 19:54 UTC, Ralek Kolemios
Details
DebugView Logs 2 (24.25 KB, text/plain)
2019-07-09 11:31 UTC, Ralek Kolemios
Details
Coalesced frame view (450.59 KB, image/png)
2019-07-09 11:35 UTC, Ralek Kolemios
Details
DebugView Logs 3 (22.62 KB, text/plain)
2019-07-09 12:24 UTC, Ralek Kolemios
Details
Canvas 'jumping' when panning (1.57 MB, video/webm)
2019-07-09 12:54 UTC, Ralek Kolemios
Details
DebugView Logs 4 (22.07 KB, text/plain)
2019-07-09 14:21 UTC, Ralek Kolemios
Details
Graphic describing the issue (261.93 KB, image/jpeg)
2019-07-09 14:46 UTC, Ralek Kolemios
Details
DebugView Logs 4.2.2 (3.40 KB, text/plain)
2019-07-09 15:03 UTC, Ralek Kolemios
Details
Updates smoothing skip (1.78 MB, video/webm)
2019-07-10 17:54 UTC, Ralek Kolemios
Details
Time graph animation (298.75 KB, video/webm)
2019-07-11 14:09 UTC, Ralek Kolemios
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ralek Kolemios 2019-07-03 13:42:04 UTC
Created attachment 121306 [details]
High speed footage of the rendering issue

SUMMARY
When the canvas is dragged using the pan tool from one side to another at a constant velocity, it consistently 'skips' every other frame. The 'missing' frame is not actually missing or dropped, but rather "timed" incorrectly, producing the effect of a halved FPS.
Hard to explain, much easier to show. I used a high speed camera to capture the effect because I was curious what made the canvas seem low FPS despite diagnostics showing 60.



STEPS TO REPRODUCE
1. Open any document, large or small, at any zoom level.
2. Using the pan tool, drag the canvas from one side to the other at a constant velocity
3. While it may be hard to see with the naked eye, every other frame is rendered very similarly to the previous frame (but not exactly, it's still an entirely new frame)

OBSERVED RESULT
If I drag the letter "I" across the canvas, the frames that are rendered look like this when overlayed on top of each other:
II   II   II   II   II


EXPECTED RESULT
Because I am dragging at a constant velocity, I would expect the distance between the "I"s (or frames) to be constant, like so:
I  I  I  I  I  I  I  I



ADDITIONAL INFORMATION

-A 1000 FPS capture of the effect I'm seeing is attached, notice the 'plus' is not evenly distributed among the frames, but rather alternate from 'small jump -> big jump'

-The same effect happens whether the canvas is accelerated with either OpenGL or ANGLE, but not with acceleration turned off (though it may just be too low FPS to notice)

-Setting 'max brush render fps' doesn't affect this as it's unrelated to the brush rendering itself.

-I was linked this bug: https://bugs.kde.org/show_bug.cgi?id=386620
But I do not believe it is a duplicate, though may be related in some abstract way

-When I use a mouse to drag the canvas, the effect seems mitigated or even nonexistent, but instead the canvas occasionally drops several frames each second randomly. (between 5-10 'missing' frames per 60 rendered)



Krita
  Version: 4.2.2

Qt
  Version (compiled): 5.12.4
  Version (loaded): 5.12.4

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


OpenGL Info
 
  Vendor:  "NVIDIA Corporation" 
  Renderer:  "GeForce GTX 980 Ti/PCIe/SSE2" 
  Version:  "4.6.0 NVIDIA 430.86" 
  Shading language:  "4.60 NVIDIA" 
  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 4.6, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples 0, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 1, colorSpace QSurfaceFormat::sRGBColorSpace, profile  QSurfaceFormat::CompatibilityProfile) 
     Version: 4.6
     Supports deprecated functions true 
     is OpenGL ES: false 

QPA OpenGL Detection Info 
  supportsDesktopGL: true 
  supportsAngleD3D11: true 
  isQtPreferAngle: false 
== log ==
 Supported renderers: QFlags(0x2|0x4) 
Surface format preference list: 
* 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) 
    QSurfaceFormat::OpenGL 
* 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) 
    QSurfaceFormat::OpenGLES 
* QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 16, greenBufferSize 16, blueBufferSize 16, alphaBufferSize 16, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::scRGBColorSpace, profile  QSurfaceFormat::CompatibilityProfile) 
    QSurfaceFormat::OpenGL 
* QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 10, greenBufferSize 10, blueBufferSize 10, alphaBufferSize 2, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::bt2020PQColorSpace, profile  QSurfaceFormat::CompatibilityProfile) 
    QSurfaceFormat::OpenGL 
* QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 16, greenBufferSize 16, blueBufferSize 16, alphaBufferSize 16, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::scRGBColorSpace, profile  QSurfaceFormat::CompatibilityProfile) 
    QSurfaceFormat::OpenGLES 
* QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 10, greenBufferSize 10, blueBufferSize 10, alphaBufferSize 2, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::bt2020PQColorSpace, profile  QSurfaceFormat::CompatibilityProfile) 
    QSurfaceFormat::OpenGLES 
Probing format... QSurfaceFormat::DefaultColorSpace QSurfaceFormat::OpenGL 
Found 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) 
    QSurfaceFormat::OpenGL 
 
== end log == 

Hardware Information
 Memory: 63 Gb
 Cores: 12
 Swap: C:/Windows/Temp
Comment 1 Halla Rempt 2019-07-03 18:12:51 UTC
Krita doesn't try to render at 60 fps: it tries to render its frames as soon as possible. There is no fixed framerate in Krita: we did try a fixed framerate of 60fps, but that was not fast enough for some artists.

You can enable "Debug logging of OpenGL framerate" in the Performance Page, Advanced tab in Krita's settings dialog. This shows the actual framerate counter in Krita's canvas. I can easily get over 100 fps when panning on my KDE Plasma desktop or on Windows, even when Krita isn't full-screen. This is all on Intel integrated GPU's.

I'm not sure which diagnosics you were using? And I'm also not sure what you mean with "Setting 'max brush render fps'" unless you mean "Limit frames per second while painting"?
Comment 2 Ralek Kolemios 2019-07-03 23:48:28 UTC
The 'diagnostics' I'm referring to are the 'Debug logging of OpenGL framerate' outputs. Which as I said in the original post, do show 100+ fps (or 60 fps if vsync is forced on in nvidia settings)

What Krita is 'theoretically rendering at' has no bearing on this issue as it's a frame distribution issue rather than an actual framerate issue. The canvas is rendered, somehow, in such a way that it gives the appearance to the naked eye as only being 30 FPS rather than the 100+ FPS that the debug logging talks about.

I assumed that the canvas appearing to the naked eye was half the FPS of the screen it's on was unintentional so I decided to try and figure out what exactly is going on behind the scenes to cause it to act this way. I'm still not entire sure what is going on with it.

I can record a comparison video of what Krita's doing vs what I expect it to do if it would help further explain my case.
Comment 3 Ralek Kolemios 2019-07-04 01:11:35 UTC
Created attachment 121316 [details]
Emulated example of rendering issue
Comment 4 Ralek Kolemios 2019-07-04 09:09:14 UTC
Updated scope:
I've asked several artist friends of mine to see if they notice it, and each one (all windows 10, various hardware) said they notice it doesn't seem smooth.

I've installed a dual-boot of Ubuntu 19.04 on my primary desktop to see if that works, but the same exact issue is occurring in that environment as well. Frames are 'skipping' just like on windows, despite the canvas rendering at over 60FPS
Comment 5 Dmitry Kazakov 2019-07-08 16:56:29 UTC
Hi, Aaron!

Could you please check if this package has higher FPS on your machine? It has higher priority for screen updates...

https://yadi.sk/d/PnfCWZ_Dq2KgCw
Comment 6 Dmitry Kazakov 2019-07-08 19:05:11 UTC
If you still have a problem with the package, please try to generate the FPS log for me:

1) Download DebugView and start it: https://docs.microsoft.com/en-us/sysinternals/downloads/debugview
2) Start 'cmd.exe'
3) Type: set QT_DEBUG_FPS=1
4) Type the path to Krita executable: C:\Path_To_Krita_Package\bin\krita.exe
5) When Krita starts, start panning an pan continuosly for at least 15 seconds (you'll see three messages in DebugView reporting FPS, they appear every 5 seconds).

Attach the result to the bug. 

It would be also interesting for me to see FPS log for the release 4.2.2 package.

PS:
On my system FPS is 140fps whatever the settings are, so I cannot see any difference.
Comment 7 Ralek Kolemios 2019-07-08 19:44:25 UTC
Created attachment 121399 [details]
DebugView logs
Comment 8 Ralek Kolemios 2019-07-08 19:49:28 UTC
Hey Dmitry, this package seems to be noticeably smoother, though it's hard to tell.
Taking more high speed footage, I've found that instead of getting 'stuck' every other frame, it's now only getting stuck every couple of frames. So It's still stuttery on my end, though smoother in general.
Turning on QT's FPS debug causes the canvas to hang every second, giving a lower FPS of ~32 in the debug logs, though when I use Krita's built-in OpenGL FPS reporter, it shows a consistent 100+ FPS in the upper left corner.
Comment 9 Ralek Kolemios 2019-07-08 19:54:59 UTC
Created attachment 121400 [details]
New package slow motion

Notice how the blue cross moves at an inconsistent speed, despite the cursor updating correctly.
Comment 10 Dmitry Kazakov 2019-07-09 10:56:15 UTC
Hi, Aaron!

Do I understand it right that you see "FPS: 30..." lines in the DebugView? 

The problem is, I cannot get such FPS on my system. Whatever GPU settings I set, it doesn't get lower than 100fps :(

Btw, can you try go to the driver setting and try to disable "Vertical Synchronization (VSync)" option? Does it change anything?
Comment 11 Dmitry Kazakov 2019-07-09 11:03:44 UTC
Ah... I see the log now. Let me make another package, without this extra tablet debug
Comment 12 Ralek Kolemios 2019-07-09 11:08:42 UTC
Because of intermittent freezing when using DebugView, yes I see ~30 FPS lines.

When I'm not using DebugView (such as with normal use) I see 100+ FPS like you. "Canvas FPS: 104.3" But the canvas is still very choppy and the frames are inconsistent.

When I force vertical sync off in NVidia settings for Krita, I get screen tearing on top of the inconsistent frames.
When I force vertical sync on, it almost seems choppier and less responsive than it was already.

Maybe I'm not explaining the issue correctly, it's hard to explain. My system is rendering enough frames, since the canvas does in fact update at least 60 times per second as shown by the high speed footage. It doesn't skip frames, and there's no tearing.
But the distances between the 'updates' are so wildly inconsistent, almost random, that it makes the canvas appear extremely choppy.

For example- if I had a theoretical pen that panned the canvas at a perfectly constant speed, I would assume that the distance between 'where' the canvas is in each frame positionally would also be consistent. Instead, it's seemingly random.
Comment 13 Dmitry Kazakov 2019-07-09 11:14:49 UTC
Hi, Aaron!

Could you please check this new package? It should work smoothly and without freezes on your system:

https://yadi.sk/d/lEf3ffTL6qkAGw

As with the previous package, please generate a log:

1) Start DebugView
2) Start 'cmd.exe'
3) Type: set QT_DEBUG_FPS=1
4) Type the path to Krita executable: C:\Path_To_Krita_Package\bin\krita.exe
5) When Krita starts, start panning an pan continuosly for at least 15 seconds (you'll see three messages in DebugView reporting FPS, they appear every 5 seconds).
Comment 14 Ralek Kolemios 2019-07-09 11:31:23 UTC
Created attachment 121415 [details]
DebugView Logs 2
Comment 15 Ralek Kolemios 2019-07-09 11:35:53 UTC
Created attachment 121416 [details]
Coalesced frame view

Grey square is canvas, with white plus for positional clarity.
Stacked frames from high speed footage of two different programs. Total of 10 frames each.
Top half is another drawing program I would consider very 'smooth' when it comes to zooming/panning. Bottom is Krita, which supposedly is rendering at higher FPS but seems less smooth in comparison.
Looking at the distribution of the pluses, you can see why. The upper pluses are equidistant while the lower ones have a variable distance between them, despite both rendering at a consistent 60FPS.
Comment 16 Dmitry Kazakov 2019-07-09 12:08:16 UTC
Okay, can you test this package as well? On my system it gives 596fps :)

https://yadi.sk/d/PaqidZxK7d_S8g
Comment 17 Ralek Kolemios 2019-07-09 12:24:14 UTC
Created attachment 121419 [details]
DebugView Logs 3

I can tell it's "faster", but it's just still extremely "not right" and "stuttery"
I don't know how to explain it, I don't believe it is a bottleneck/low fps issue. It's still extremely jittery, with mouse or pen dragging. I'll get more footage in a bit.
Comment 18 Ralek Kolemios 2019-07-09 12:54:25 UTC
Created attachment 121420 [details]
Canvas 'jumping' when panning
Comment 19 Dmitry Kazakov 2019-07-09 14:05:42 UTC
Can you try this package?

https://yadi.sk/d/mCAnrkEIJaC0iQ

Btw, are you sure you use Space+Click shortcut? Not Pan or Move tool?
Comment 20 Ralek Kolemios 2019-07-09 14:21:59 UTC
Created attachment 121424 [details]
DebugView Logs 4

Yes the frame timing issue happens with both space+click and the pan tool. I'm not using the move tool. It also occurs with rotating, and scrubby zooming.

I don't believe it's an issue with how many frames are being generated or the priority they are placed at, I've always gotten over 100 FPS on all my canvases. Especially on these builds which go up to 200 or 300 FPS.
It's an issue with the relative position of the canvas between frames. If the canvases that are drawn on each frame aren't equidistant from each other, it gives an illusion of lower FPS or missing frames. When in actuality it's always been a solid 60 FPS.
Comment 21 Dmitry Kazakov 2019-07-09 14:27:10 UTC
Erm... you said you had low FPS on in Krita 4.2.2... can you generate QT_DEBUG_FPS log for the original unchanged Krita 4.2.2 binary?
Comment 22 Ralek Kolemios 2019-07-09 14:46:31 UTC
Created attachment 121425 [details]
Graphic describing the issue

I don't have low FPS, just the effect of low FPS due to the canvas being rendered at sporadic intervals as I said in the original report:

(In reply to Aaron Lavarnway from comment #0)
>The 'missing' frame is not actually missing or dropped, but rather "timed" incorrectly, producing the effect of a halved FPS.
>I was curious what made the canvas seem low FPS despite diagnostics showing 60.

I know it's a weird report, which is why I'm trying my best to explain it in an understandable way. Thank you for your help so far, it means a lot. It's mostly my fault for not finding a good way to explain the issue.
Comment 23 Ralek Kolemios 2019-07-09 15:03:31 UTC
Created attachment 121426 [details]
DebugView Logs 4.2.2
Comment 24 Ralek Kolemios 2019-07-09 16:09:24 UTC
I've been asking around to some other artists, and this seems to be a widespread issue.
So far it's been confirmed happening on:
Win 10       / GTX 980TI  / 64GB (mine)
Ubuntu 19.04 / GTX 980TI  / 64GB (mine, dual booted)
Win 10       / GTX 1080   / 16GB 
Win 10       / GTX 2080   / 16GB
Win 10       / GTX 2080TI / 16GB
Ubuntu 16.04 / GTX 1080TI / 16GB
Win 10       / GTX 1060   / 16GB

And I still have friends checking their own, so the list may grow. But so far I haven't found anyone who isn't having this issue. I have slow motion footage from each of my friend's computers as well that I had asked for.

It has to be something deeper in how Krita handles panning/zooming. I know as someone who stares at Krita 6-8 hours a day it can get a bit frustrating or grating. Possibly even nauseating.
Comment 25 Halla Rempt 2019-07-09 16:14:16 UTC
That sounds like a set of graphics cards with very little diversity... I cannot reproduce it, or maybe I just cannot see this, but I mainly use Intel GPU based systems. Maybe that's relevant, too.

Does this also happen if you disable GPU acceleration? And that "other application" you were talking about, does that use GPU acceleration? Or only software rendering?
Comment 26 Ralek Kolemios 2019-07-09 16:22:29 UTC
Unfortunately I don't have many friends with other graphics cards so I didn't mean for the list to be an all-encompassing sample set.

The issue is still there when using software rendering. But in addition to the frame 'timing' being off, it also drops frames since it's not rendering under 60FPS.

The other software I talked about's main selling point is that it's entirely GPU based, so yes it is utilizing the card as well.
Comment 27 Ralek Kolemios 2019-07-09 16:23:20 UTC
(In reply to Aaron Lavarnway from comment #26)
> it also drops frames since it's not rendering under 60FPS.

*since it is now rendering under 60FPS
Comment 28 Dmitry Kazakov 2019-07-09 16:44:41 UTC
Hm... that sound a bit weird... I though that the packages (-dk3 and -dk4) made panning better for you, but it seems like it didn't...

Can I ask you for an experiment? Could you try to paint with "Basic 5 Size" with three different smoothing configurations?

Configuration 1) 
Preset: "Basic 5 Size"
Size: 100px
Brush Smoothing: Basic Smoothing

Configuration 2) 
Preset: "Basic 5 Size"
Size: 100px
Brush Smoothing: Stabilizer
Distance: 3.0
Delay: Off
Finish Line: On
Stabilize Sensors: On
Scalable Distance: **On**

Configuration 3) 
Preset: "Basic 5 Size"
Size: 100px
Brush Smoothing: Stabilizer
Distance: 3.0
Delay: Off
Finish Line: On
Stabilize Sensors: On
Scalable Distance: **Off**

The question I'd like you to answer: do you feel that configurations 2 and 3 are "smoother" than configuration 1? Do they have more uniform brush rendering spacing?

PS:
If they do, I can think about reusing brush smoothing algorithms in other places...
Comment 29 Dmitry Kazakov 2019-07-09 16:46:12 UTC
Btw, what is your graphical tablet/display model? It it something Cintiq-like?
Comment 30 Ralek Kolemios 2019-07-09 16:55:10 UTC
I was actually thinking the same thing about re-using a brush stabilizer  for things like panning, zooming and rotating. But I don't understand how all of the behind-the-scenes works so I didn't suggest it in case it was a monumental task.

I personally like 'Basic' stabilizer more, though i'm used to drawing with very little stabilizer.
['Weighted', distance: 3, ending: 0.25, pressure: on, distance: off] for my daily stuff

I use a Cintiq Pro 24 with Pro Pen 2.
Comment 31 Dmitry Kazakov 2019-07-10 15:27:32 UTC
Hi, Aaron!

Could you please test "Space+drag" panning with this package?

https://yadi.sk/d/e_eWFr3MwGLLbA


I have added a simple stabilizer there. It should generate precisely 60fps and do the dragging smoothly. The only disadvantage of this approach is that it introduces a 30ms delay to the dragging... 

But the main question I want to answer: it the dragging smooth now?

PS:
Mind you, Pan Tool doesn't have any smoothing implemented, only Shift+drag action!
Comment 32 Ralek Kolemios 2019-07-10 17:54:22 UTC
Created attachment 121447 [details]
Updates smoothing skip

While it is slightly 'smoother', unfortunately the frames themselves aren't rendered smoothly.

Attached is more high speed footage of how it renders the frames, you'll notice that every once in a while (highlighted with a red arrow) the frames jump out of place, and render right 'next' to the previous frame. You can see it in slow motion, but in regular use it just appears to be an entirely skipped frame. And skipped frames don't make for smooth panning.

On the left of the attached video is 4.2.2 and the right is the package you just gave me.
Comment 33 Dmitry Kazakov 2019-07-11 10:43:25 UTC
Could you test this one as well? I guess I managed to reproduce it on my system...

https://yadi.sk/d/rjvDg4K_T_vLoA
Comment 34 Ralek Kolemios 2019-07-11 14:09:53 UTC
Created attachment 121469 [details]
Time graph animation

Unfortunately not, as far as I can tell.

I attached another graphic that shows the problem, since that's about all I can do to help. I created a mouse macro to drag the canvas of Krita and an example program so I could reproduce the exact mouse movements and compare the two. Then I laid out each frame on a time graph, so you can visually see the 'stuttering' and 'bumps' that occur.
Comment 35 Dmitry Kazakov 2019-07-11 14:32:16 UTC
It looks much better than it used to be, right?

And what is "the other" application you are checking it against?
Comment 36 Ralek Kolemios 2019-07-11 14:43:31 UTC
Paintstorm Studio is the 'other', though Affinity Photo also has very smooth pan/zoom/rotate. I used Clip Studio Paint for 5 years, then when I upgraded to the 4k Cintiq the canvas FPS dropped to ~12-20 FPS at all times. No fix currently.
So I switched to Paintstorm for about a year, but found it handled large files/many layers terribly and lacked many, many features. Now I've been using Krita for about 6 months, but I always noticed the canvas was choppier, but usable. 
I tried to switch from Krita to Affinity Photo but Affinity doesn't have a way to switch to zoom temporarily when you hold down the zoom shortcut, and doesn't allow you to rotate by dragging.

So Krita is the best option for me and my workflow currently. The only problem I've ever had so far was the canvas being stuttery. And if I'm going to be sticking around with it, I might as well see if that could potentially help get it fixed.
I don't know if you take bug bounties, but it matters enough to me and my friends where I could try and scrounge up something for the effort, whatever you think would be fair I could look into saving for.
Comment 37 Ralek Kolemios 2019-07-11 17:04:30 UTC
(In reply to Dmitry Kazakov from comment #35)
> It looks much better than it used to be, right?

It does look better than it used to be, that's for sure. But that got fixed when I did a clean wipe of all display drivers and reinstalled the latest Nvidia drivers. That, as well as all my friends and other computers with Nvidia cards having the same problem, suggests it might have something to do with Nvidia cards, how Krita communicates with them, or drivers, right? I don't know much about how that works, and unfortunately I don't have an AMD or Intel integrated computer to test it out.
Comment 38 Dmitry Kazakov 2019-07-11 18:14:23 UTC
Erm.. I don't understand. What happened after you cleaned-up the drivers? 

1) Did 4.2.2 started to work smoother? 
2) Or my latest package started to work smoother? 
3) Or my latest package started to work less smoothly?
Comment 39 Ralek Kolemios 2019-07-11 18:48:03 UTC
Sorry for the confusion.
Shortly after figuring out why the canvas wasn't smooth, I did a few tests of my own such as updating drivers, trying on different screens, using the mouse to pan instead of the tablet, updating tablet drivers, etc.

When none of those worked, I posted this thread in search of answers. In the meantime, I did some more tests. I installed a dual-boot of Ubuntu and tested it there, I started asking friends to document their own experience, etc. 
Around that time I decided to install Krita on a second computer of mine, and it ran noticeably smoother (but not entirely smooth, it has the same hiccups we're dealing with now)

I figured it was something weird with my main computer, so I decided to do a full clean install of my display drivers using Display Driver Uninstaller. When I tested again, it was as smooth as the other computer was. This was before you ever sent a test build, and none of the builds have made the stuttering better than stock 4.2.2 from what I've experienced.

So yes, the issue has gotten better in comparison to when I first posted, but I still find the stutter rather bothersome to work with for long hours.
Comment 40 Dmitry Kazakov 2019-07-12 07:18:34 UTC
Hi, Aaron!

Could you please test this build? I guess I located the point, where the drop of frames happens...

https://yadi.sk/d/ILNKZ-VOXGLU0w
Comment 41 Ralek Kolemios 2019-07-12 13:19:15 UTC
Wow! DK7 completely fixed it. It feels significantly smoother now when space+panning. When directly comparing it to the pan tool, it's like night and day.

If you got rid of the panning stabilizer (or reduce it a whole lot), and fix the stuttering on the rotate mode/relative zoom mod(?) in the same way, that'd be an absolutely perfect fix.

Found a bug as well:
If you click the UI, such as the layers panel, then immediately go back to space+drag to pan the canvas, it 'skips' frames again and acts the same as the pan tool. But if I click the canvas, then use space+drag, it's smooth as butter.

Speaking of the relative zoom, it usually dips in the ~40 fps range (while rotate/pan are 100+), but that might just be my computer not being powerful enough, or some other factor. I don't know if it's easy to change the priority of that or find out why it may be drawing so many resources.

Thank you for your time!
Comment 42 Dmitry Kazakov 2019-07-12 17:23:24 UTC
Git commit bbc0f80732afbf0cb36ccdf5fd6b672dd15712a6 by Dmitry Kazakov.
Committed on 12/07/2019 at 17:04.
Pushed by dkazakov into branch 'master'.

Refactor signal compressor to have better timing properties

* before: emits signals with time range [1.0...2.0] * interval
* after: emits signals with time range [0.5...1.5] * interval

Bascially, now it handles it much better when interval is around
10-20 ms. With the old version it caused KisCanvas2 to drop frames
and look ugly when the user pans the canvas.

M  +100  -34   libs/global/kis_signal_compressor.cpp
M  +12   -4    libs/global/kis_signal_compressor.h
M  +1    -0    libs/global/tests/CMakeLists.txt
A  +101  -0    libs/global/tests/KisSignalCompressorTest.cpp     [License: GPL (v2+)]
A  +33   -0    libs/global/tests/KisSignalCompressorTest.h     [License: GPL (v2+)]

https://invent.kde.org/kde/krita/commit/bbc0f80732afbf0cb36ccdf5fd6b672dd15712a6
Comment 43 Dmitry Kazakov 2019-07-12 17:23:24 UTC
Git commit a8524451df4cec75128a09993c326bf1583ee3ce by Dmitry Kazakov.
Committed on 12/07/2019 at 17:08.
Pushed by dkazakov into branch 'master'.

Add hi-res input events support to Pan/Zoom/Rotate

M  +5    -0    libs/ui/input/kis_pan_action.cpp
M  +1    -0    libs/ui/input/kis_pan_action.h
M  +5    -0    libs/ui/input/kis_rotate_canvas_action.cpp
M  +1    -0    libs/ui/input/kis_rotate_canvas_action.h
M  +5    -0    libs/ui/input/kis_zoom_action.cpp
M  +1    -0    libs/ui/input/kis_zoom_action.h

https://invent.kde.org/kde/krita/commit/a8524451df4cec75128a09993c326bf1583ee3ce
Comment 44 Dmitry Kazakov 2019-07-12 17:23:28 UTC
Git commit ce83d7bc5dc84b27db6efc88098dfc7d0eafd7fe by Dmitry Kazakov.
Committed on 12/07/2019 at 17:08.
Pushed by dkazakov into branch 'master'.

Drop KisRelaxedTimer

It is not used anymore

M  +0    -1    libs/global/CMakeLists.txt
D  +0    -108  libs/global/kis_relaxed_timer.cpp
D  +0    -99   libs/global/kis_relaxed_timer.h

https://invent.kde.org/kde/krita/commit/ce83d7bc5dc84b27db6efc88098dfc7d0eafd7fe
Comment 45 Dmitry Kazakov 2019-07-12 17:35:18 UTC
Hi, Aaron!

Could you please test this package: https://yadi.sk/d/rpQqlX13xHbOWQ

This is the final version of the fix. Does it work well your system?
Pan and Rotate should work smoothly. Zooming is slow for some reason, but it is some different problem. It needs investigation.
Comment 46 Ralek Kolemios 2019-07-12 18:11:56 UTC
Panning and Rotating works great!

New bug arises though-
If I rotate the canvas back and forth without picking the pen up, the canvas 'drifts' up and to the left.
Comment 47 Dmitry Kazakov 2019-07-12 20:22:03 UTC
> New bug arises though... If I rotate the canvas back and forth without picking the pen up

That's an old bug :) I'll try to fix it later.
Comment 48 Dmitry Kazakov 2019-07-17 10:38:11 UTC
Git commit 63bef1e49334f67b4bb8549e427fdb59e119a6b0 by Dmitry Kazakov.
Committed on 17/07/2019 at 10:37.
Pushed by dkazakov into branch 'master'.

Fix cursor drift when Pan/Zoom/Rotate

The actions should use absolute values for pan/zoom/rotation to
avoid relative drift between canvas and cursor.

NOTE: rotation still drifts a bit because of a bud in the underlying
      algorithm.

M  +9    -0    libs/ui/input/kis_abstract_input_action.cpp
M  +1    -0    libs/ui/input/kis_abstract_input_action.h
M  +6    -6    libs/ui/input/kis_gamma_exposure_action.cpp
M  +1    -1    libs/ui/input/kis_gamma_exposure_action.h
M  +5    -3    libs/ui/input/kis_pan_action.cpp
M  +1    -1    libs/ui/input/kis_pan_action.h
M  +15   -17   libs/ui/input/kis_rotate_canvas_action.cpp
M  +1    -1    libs/ui/input/kis_rotate_canvas_action.h
M  +28   -22   libs/ui/input/kis_zoom_action.cpp
M  +1    -1    libs/ui/input/kis_zoom_action.h
M  +3    -3    libs/ui/input/kis_zoom_and_rotate_action.cpp
M  +1    -1    libs/ui/input/kis_zoom_and_rotate_action.h

https://invent.kde.org/kde/krita/commit/63bef1e49334f67b4bb8549e427fdb59e119a6b0
Comment 49 Dmitry Kazakov 2019-07-17 10:59:45 UTC
The original bug is fixed now. I have reported other bugs you mentioned as separate tickets:

Zooming with ctrl+space+drag is not smooth
https://bugs.kde.org/show_bug.cgi?id=409892

Rotation Shift+Space action drifts when rotating
https://bugs.kde.org/show_bug.cgi?id=409894
Comment 50 Ralek Kolemios 2019-07-18 03:15:13 UTC
Awesome, I'll follow those as well. Thank you for all the help!
Comment 51 Halla Rempt 2019-07-29 08:35:37 UTC
Git commit 1a1cce8cd5ba3e357c9d81fffedaf78b55d65d68 by Boudewijn Rempt, on behalf of Dmitry Kazakov.
Committed on 29/07/2019 at 08:33.
Pushed by rempt into branch 'krita/4.2'.

Fix cursor drift when Pan/Zoom/Rotate

The actions should use absolute values for pan/zoom/rotation to
avoid relative drift between canvas and cursor.

NOTE: rotation still drifts a bit because of a bud in the underlying
      algorithm.

M  +9    -0    libs/ui/input/kis_abstract_input_action.cpp
M  +1    -0    libs/ui/input/kis_abstract_input_action.h
M  +6    -6    libs/ui/input/kis_gamma_exposure_action.cpp
M  +1    -1    libs/ui/input/kis_gamma_exposure_action.h
M  +5    -3    libs/ui/input/kis_pan_action.cpp
M  +1    -1    libs/ui/input/kis_pan_action.h
M  +15   -17   libs/ui/input/kis_rotate_canvas_action.cpp
M  +1    -1    libs/ui/input/kis_rotate_canvas_action.h
M  +28   -22   libs/ui/input/kis_zoom_action.cpp
M  +1    -1    libs/ui/input/kis_zoom_action.h
M  +3    -3    libs/ui/input/kis_zoom_and_rotate_action.cpp
M  +1    -1    libs/ui/input/kis_zoom_and_rotate_action.h

https://invent.kde.org/kde/krita/commit/1a1cce8cd5ba3e357c9d81fffedaf78b55d65d68
Comment 52 Ralek Kolemios 2019-08-08 01:31:20 UTC
On the most recent nightly build (and the most recent test build you've given me), it's fixed. But I think It also applies some sort of smoothing/stabilization to the pen in general. Including brushes, even if stabilization is set off.
Comment 53 Ralek Kolemios 2019-08-08 01:33:44 UTC
Aha, I found the issue. Nvidia had vertical sync forced on, which added significant drawing/panning delay.
Comment 54 Halla Rempt 2019-08-11 10:26:41 UTC
Ah, thanks for telling us. I'll add that to the FAQ.
Comment 55 Dmitry Kazakov 2019-10-08 18:41:05 UTC
Git commit 34f3a4a815b3e489eeb4397045738eb2aa74e2d8 by Dmitry Kazakov.
Committed on 08/10/2019 at 18:13.
Pushed by dkazakov into branch 'krita/4.2'.

Refactor signal compressor to have better timing properties

* before: emits signals with time range [1.0...2.0] * interval
* after: emits signals with time range [0.5...1.5] * interval

Bascially, now it handles it much better when interval is around
10-20 ms. With the old version it caused KisCanvas2 to drop frames
and look ugly when the user pans the canvas.

# Conflicts:
#	libs/global/tests/CMakeLists.txt

M  +100  -34   libs/global/kis_signal_compressor.cpp
M  +12   -4    libs/global/kis_signal_compressor.h
M  +1    -0    libs/global/tests/CMakeLists.txt
A  +101  -0    libs/global/tests/KisSignalCompressorTest.cpp     [License: GPL (v2+)]
A  +33   -0    libs/global/tests/KisSignalCompressorTest.h     [License: GPL (v2+)]

https://invent.kde.org/kde/krita/commit/34f3a4a815b3e489eeb4397045738eb2aa74e2d8
Comment 56 Dmitry Kazakov 2019-10-08 18:41:06 UTC
Git commit 19163b2b9461ff57f58d74bd22646bca8d20d41c by Dmitry Kazakov.
Committed on 08/10/2019 at 18:38.
Pushed by dkazakov into branch 'krita/4.2'.

Add hi-res input events support to Pan/Zoom/Rotate

M  +5    -0    libs/ui/input/kis_pan_action.cpp
M  +1    -0    libs/ui/input/kis_pan_action.h
M  +5    -0    libs/ui/input/kis_rotate_canvas_action.cpp
M  +1    -0    libs/ui/input/kis_rotate_canvas_action.h
M  +5    -0    libs/ui/input/kis_zoom_action.cpp
M  +1    -0    libs/ui/input/kis_zoom_action.h

https://invent.kde.org/kde/krita/commit/19163b2b9461ff57f58d74bd22646bca8d20d41c
Comment 57 Dmitry Kazakov 2019-10-08 18:41:06 UTC
Git commit 265141f4e283cd4389d53e165677cfad89b48a0b by Dmitry Kazakov.
Committed on 08/10/2019 at 18:38.
Pushed by dkazakov into branch 'krita/4.2'.

Drop KisRelaxedTimer

It is not used anymore

M  +0    -1    libs/global/CMakeLists.txt
D  +0    -108  libs/global/kis_relaxed_timer.cpp
D  +0    -99   libs/global/kis_relaxed_timer.h

https://invent.kde.org/kde/krita/commit/265141f4e283cd4389d53e165677cfad89b48a0b
Comment 58 Ralek Kolemios 2021-06-21 09:36:04 UTC
I'm going to open this issue back up since both 4.4.7 and 5.0 nightly builds have this issue still. Not sure if the fix got lost or overwritten somehow.