| Summary: | Canvas pan & zoom frame 'spacing' inconsistent | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | Ralek Kolemios <info> |
| Component: | OpenGL Canvas | Assignee: | Dmitry Kazakov <dimula73> |
| Status: | RESOLVED MOVED | ||
| Severity: | normal | CC: | dimula73, halla |
| Priority: | NOR | ||
| Version: | nightly build (please specify the git hash!) | ||
| Target Milestone: | --- | ||
| Platform: | Microsoft Windows | ||
| OS: | Microsoft Windows | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
High speed footage of the rendering issue
Emulated example of rendering issue DebugView logs New package slow motion DebugView Logs 2 Coalesced frame view DebugView Logs 3 Canvas 'jumping' when panning DebugView Logs 4 Graphic describing the issue DebugView Logs 4.2.2 Updates smoothing skip Time graph animation |
||
|
Description
Ralek Kolemios
2019-07-03 13:42:04 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"? 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. Created attachment 121316 [details]
Emulated example of rendering issue
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 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 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. Created attachment 121399 [details]
DebugView logs
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. Created attachment 121400 [details]
New package slow motion
Notice how the blue cross moves at an inconsistent speed, despite the cursor updating correctly.
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? Ah... I see the log now. Let me make another package, without this extra tablet debug 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. 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). Created attachment 121415 [details]
DebugView Logs 2
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.
Okay, can you test this package as well? On my system it gives 596fps :) https://yadi.sk/d/PaqidZxK7d_S8g 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.
Created attachment 121420 [details]
Canvas 'jumping' when panning
Can you try this package? https://yadi.sk/d/mCAnrkEIJaC0iQ Btw, are you sure you use Space+Click shortcut? Not Pan or Move tool? 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.
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? 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. Created attachment 121426 [details]
DebugView Logs 4.2.2
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. 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? 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. (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 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... Btw, what is your graphical tablet/display model? It it something Cintiq-like? 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. 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! 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.
Could you test this one as well? I guess I managed to reproduce it on my system... https://yadi.sk/d/rjvDg4K_T_vLoA 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.
It looks much better than it used to be, right? And what is "the other" application you are checking it against? 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. (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. 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? 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. 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 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! 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 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 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 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. 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. > 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.
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
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 Awesome, I'll follow those as well. Thank you for all the help! 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
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. Aha, I found the issue. Nvidia had vertical sync forced on, which added significant drawing/panning delay. Ah, thanks for telling us. I'll add that to the FAQ. 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 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 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 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. |