When drawing with the stabilizer enabled, the actual rendering of the brush location and the new image seems to be working at a noticeably slower framerate (maybe 20 FPS). I'd attach a performance log but I can't find where it's being stored, it's not in %TEMP%. Reproducible: Always Steps to Reproduce: 1. Create a new image 2. Pick a brush and enable the stabilizer 3. Start drawing Actual Results: The framerate is as smooth as drawing with the stabilizer off. Expected Results: The drawing appears to occur at 20-ish frames a second. System configuration: i5-4460 CPU, Radeon R9 390, 16 GB RAM. Krita's CPU usage doesn't go noticeably higher than when it does when I draw with the stabilizer off, and the memory usage seems reasonable.
More information I forgot to include: This doesn't occur when I use the latest 2.9 build, nor does it occur on 3.0.1 on OS X.
For which version does it occur then?
It occurs with 3.0.1 (and 3.0.1.1) on Windows.
I second that this choppyness\low framerate of the stabilizer happens on 3.0.1.1 Windows 64. The stabilizer behaviour is okay on 2.9.11 Windows 64. There's a similar report on Reddit: https://www.reddit.com/r/krita/comments/556u7k/choppy_stabilizer/
I am not sure if is related, but on my Ubuntu box, all of the brush smoothing options sliders are going pretty slow (weighted smoothing and stabilizer). If I try to change a slider like "distance" or "delay", it takes a second or two for the values to update. The other tool options sliders are very responsive to changes, so there might be something going on with it.
Are the sliders themselves slow? And does it matter whether you try to move them with a mouse or a stylus?
Can confirm. Here is a comparison on how low the framerate is (ignore the bent lines as it's not related to this bug) How smooth it should be: https://media.giphy.com/media/l0HlOa3hs4U2dATzW/source.mp4 How choppy it is now: https://media.giphy.com/media/3oz8xVp4Xx9WBlHDBm/source.mp4 (the short videos are in 60fps)
*** Bug 363739 has been marked as a duplicate of this bug. ***
Is there more information needed to mark this report as confirmed? How can I help? Regards.
*** Bug 372146 has been marked as a duplicate of this bug. ***
Git commit 37b716206829048456b302e84a4222a7503c4b4d by Alvin Wong. Committed on 15/11/2016 at 14:09. Pushed by alvinwong into branch 'krita/3.1'. Work around low framerate of stabilizer Work around low framerate of stabilizer by delaying and painting the stroke progressively. The `KisStabilizerDelayedPaintHelper` class collects the sampled events and distributes them evenly with a timestamp attached, then a timer firing at a closer interval would paint the line bit by bit in order to give a smoother user feedback. The config option `stabilizerDelayedPaintInterval` with default value `20` controls the paint interval. The delayed painting is disabled if this value is higher than `stabilizerSampleSize`, which means it is disabled by default on non-Windows system. CLose: T4182 Differential Revision: https://phabricator.kde.org/D3321 M +1 -0 libs/ui/CMakeLists.txt M +13 -0 libs/ui/kis_config.cc M +3 -0 libs/ui/kis_config.h A +85 -0 libs/ui/tool/KisStabilizerDelayedPaintHelper.cpp [License: GPL (v2+)] A +86 -0 libs/ui/tool/KisStabilizerDelayedPaintHelper.h [License: GPL (v2+)] M +44 -5 libs/ui/tool/kis_tool_freehand_helper.cpp http://commits.kde.org/krita/37b716206829048456b302e84a4222a7503c4b4d
Fixed in the latest beta.
Git commit 11f0acc2ce291a020c7b53eb38a547a095553c00 by Alvin Wong. Committed on 16/11/2016 at 10:50. Pushed by alvinwong into branch 'rempt/impex-refactoring'. Work around low framerate of stabilizer Work around low framerate of stabilizer by delaying and painting the stroke progressively. The `KisStabilizerDelayedPaintHelper` class collects the sampled events and distributes them evenly with a timestamp attached, then a timer firing at a closer interval would paint the line bit by bit in order to give a smoother user feedback. The config option `stabilizerDelayedPaintInterval` with default value `20` controls the paint interval. The delayed painting is disabled if this value is higher than `stabilizerSampleSize`, which means it is disabled by default on non-Windows system. Maniphest Tasks: T4182 Differential Revision: https://phabricator.kde.org/D3321 M +1 -0 libs/ui/CMakeLists.txt M +13 -0 libs/ui/kis_config.cc M +3 -0 libs/ui/kis_config.h A +85 -0 libs/ui/tool/KisStabilizerDelayedPaintHelper.cpp [License: GPL (v2+)] A +86 -0 libs/ui/tool/KisStabilizerDelayedPaintHelper.h [License: GPL (v2+)] M +44 -5 libs/ui/tool/kis_tool_freehand_helper.cpp http://commits.kde.org/krita/11f0acc2ce291a020c7b53eb38a547a095553c00
Created attachment 102298 [details] Bended lines appear still After these fix for Stabilizer: I noticed that I don't need anymore custom settings in kritarc file ("stabilizerSampleSize=20") for fix lagging... But without "stabilizerSampleSize=20" I get bended lines in the end of the stroke (these from "Finish Line" option). I showing this on attached image.
Git commit 768c1e6529b84b20a3446d29b765a0d8912144a4 by Alvin Wong. Committed on 18/11/2016 at 19:48. Pushed by alvinwong into branch 'rempt/impex-refactoring'. Fix bent stabilizer finishing line segment Maniphest Tasks: T4182 M +5 -1 libs/ui/tool/kis_stabilized_events_sampler.cpp M +3 -3 libs/ui/tool/kis_tool_freehand_helper.cpp http://commits.kde.org/krita/768c1e6529b84b20a3446d29b765a0d8912144a4
Git commit 927781453f601cef80cdd75ea510b1e3fb89b4a4 by Alvin Wong. Committed on 18/11/2016 at 19:51. Pushed by alvinwong into branch 'krita/3.1'. Fix bent stabilizer finishing line segment Maniphest Tasks: T4182 M +5 -1 libs/ui/tool/kis_stabilized_events_sampler.cpp M +3 -3 libs/ui/tool/kis_tool_freehand_helper.cpp http://commits.kde.org/krita/927781453f601cef80cdd75ea510b1e3fb89b4a4
Thanks Alvin for your hard work on this :).
Git commit 7d9d92a9bbcda54321c4d35150688829356d8e08 by Scott Petrovic, on behalf of Alvin Wong. Committed on 19/11/2016 at 15:23. Pushed by scottpetrovic into branch 'petrovic/impex-brush-editor-ui'. Work around low framerate of stabilizer Work around low framerate of stabilizer by delaying and painting the stroke progressively. The `KisStabilizerDelayedPaintHelper` class collects the sampled events and distributes them evenly with a timestamp attached, then a timer firing at a closer interval would paint the line bit by bit in order to give a smoother user feedback. The config option `stabilizerDelayedPaintInterval` with default value `20` controls the paint interval. The delayed painting is disabled if this value is higher than `stabilizerSampleSize`, which means it is disabled by default on non-Windows system. Maniphest Tasks: T4182 Differential Revision: https://phabricator.kde.org/D3321 M +1 -0 libs/ui/CMakeLists.txt M +13 -0 libs/ui/kis_config.cc M +3 -0 libs/ui/kis_config.h A +85 -0 libs/ui/tool/KisStabilizerDelayedPaintHelper.cpp [License: GPL (v2+)] A +86 -0 libs/ui/tool/KisStabilizerDelayedPaintHelper.h [License: GPL (v2+)] M +44 -5 libs/ui/tool/kis_tool_freehand_helper.cpp http://commits.kde.org/krita/7d9d92a9bbcda54321c4d35150688829356d8e08
Git commit 66d3859309dc409a164bfa4841d43a28c144315a by Scott Petrovic, on behalf of Alvin Wong. Committed on 19/11/2016 at 15:23. Pushed by scottpetrovic into branch 'petrovic/impex-brush-editor-ui'. Fix bent stabilizer finishing line segment Maniphest Tasks: T4182 M +5 -1 libs/ui/tool/kis_stabilized_events_sampler.cpp M +3 -3 libs/ui/tool/kis_tool_freehand_helper.cpp http://commits.kde.org/krita/66d3859309dc409a164bfa4841d43a28c144315a
I'm still with this problem, since 3.0.1.... Specs: -GTX 970 4GB Galax -AMD FX 8350 -8GB RAM -WACOM INTUOS PEN S Please someone help me I really want to go back using krita.
Which version are you using?
The lastest nightly build
Hm, that was broken for some time... But not that long. Have you tried to temporarily move your kritarc so you can test with a clean config? There are also setings subtelities that interact with your current zoom level and so on, but I haven't got the deep knowledge about that, I only heard about that in a video made by david revoy.
I tried the latest stable release, 3.1.3.6. I also compared the relevant stabiliser source to version 2.9.11, which has a very smooth stabiliser. In 2.9.11 the stabiliser poll function is set to run at every single millisecond (line 583 of kis_tool_freehand_helper.cpp from 2.9.11): void KisToolFreehandHelper::stabilizerStart(KisPaintInformation firstPaintInfo) { [...] // Poll and draw each millisecond m_d->stabilizerPollTimer.setInterval(1); m_d->stabilizerPollTimer.start(); } On 3.1.3.6 there's two hidden configuration settings that you can add to your kritarc file (see here how to find it https://docs.krita.org/KritaFAQ#Where_are_the_configuration_files_stored.3F) which I think improve the stabilizer feedback. At the beginning of my kritarc file I added these lines: stabilizerDelayedPaintInterval=999 stabilizerSampleSize=16 Both lines are needed. What they do is disable the delayed paint helper (because of this condition here https://github.com/KDE/krita/blob/e7a35329b23e2cb5c832f562ddf800889e6f342f/libs/ui/tool/kis_tool_freehand_helper.cpp#L632) and make the stabilizer sample and redraw at 16ms, or 60 FPS. This makes it visually similar to 2.9.11. One could use... stabilizerDelayedPaintInterval=999 stabilizerSampleSize=1 ...to make it even faster I guess (and make it exactly like 2.9.11), but if your monitor displays at 60 FPS then in theory it shouldn't make a difference.
I wanted to add that the reason why 'stabilizerSampleSize' is not 16 or 1, but 50 by default on Windows, is because of a bended lines bug that has some history: - https://bugs.kde.org/show_bug.cgi?id=362445#c14 - https://github.com/KDE/krita/commit/23cbbf8b73cdd6c24a82ab70c8269df2b69a4ef7#diff-b7c6e6f074d19368dfa17f44b831f5c4R1662 But this value of 50 results in a visual feeling of around 20 FPS, so it's like a tradeoff? I understand now what the delayed paint helper does, it takes that 20 FPS sampling and tries to display it smoother. If you don't have the bended lines problem, use a lower interval (set a lower 'stabilizerSampleSize' value in your kritarc like explained before, which is the interval in milliseconds between stabiliser updates).
*** Bug 379870 has been marked as a duplicate of this bug. ***
How is this suddenly a problem again? I briefly checked the code and I couldn't see any major changes since my fix last year. I also tried the latest nightly just now to check, and it seems to behave exactly the same as before. One thing though, is that the default value of `stabilizerDelayedPaintInterval` is set to 20, which results in a 50Hz update rate. On most systems however, the default refresh rate of the monitor output is set to 60Hz, which if the screen is redrawn 50 times in a second, does cause some minor stuttering. But that is nowhere near as bad as the 20Hz used before the fix. Sure, it isn't as good as in Krita 2.9, but in this case the stabilizer in Krita 2.9 had always been working incorrectly so it's not really comparable. In case you do want a better "redraw rate" (!) that matches the refresh rate of your monitor, do the maths 1000 / <monitor refresh rate>, round the result down to the nearest integer (full number without decimal point) and set the `stabilizerDelayedPaintInterval` config to that value. For example, if the refresh rate of your monitor is 60, the maths will be 1000 / 60 ~= 16, then you would add `stabilizerDelayedPaintInterval=16` (without quotes) to the config, or replace the existing config value of it. If the refresh rate is 75, then it would be 1000 / 75 = 13. Why I didn't use `stabilizerDelayedPaintInterval=16` as the default though, I don't really remember what I was thinking. So if anyone think it should be changed, feel free to discuss it with @Boud. Or if perhaps there are other ways to do it properly that I didn't think of, feel free to implement it. Someone may consider adding it to the manual. (!): Note that the redraw rate does not directly translate to resulting framerate, because v-sync and double buffering exist.
I don't know either, I'm fine with setting the default to something else, of course.
Hello, thanks for the fast answer. I added the line 'stabilizerDelayedPaintInterval=16' to my kritarc-file in \Appdata\Local\krita but I can't see or feel any changes. I also tried diffrent values for testing (2, 4, 64 and 250) and restarted Krita after every change in the config file but it always looks and feels like before. I don't think the line changes anything. this is weird. Maybe the problem is my system (graphics card)?
Ok, I am sorry. I changed the wrong config file the whole time. My bad! Adding the line works good for me! Thank you (also for the good explanation of the problem). But maybe it should be default. As far as I know the most Monitors nowadays are working with at least 60hz (except theese new fancy 144hz gaming monitors).
Hi Alvin, thank you for getting back to this. I think the delayed painter you wrote is not going to help in this situation. Let me explain. According to this (https://phabricator.kde.org/T4182#62709), Dmitry observed that the longest delay between window manager updates was about 50ms. So the window manager was having slow updates while the stabilizer poll timer was going fast (as they're threaded), accumulating the same position over several times. That's what causes the bent lines problem. But that was on his tests, on his system. Maybe some user's system will have window manager delays of 60ms or more? Forcing the visual updates (what the delayed painter is doing) when the window manager can't keep up with visual updates in the first place is not going to give the expected result, it would stutter anyway. Therefore, I think the best possible timer interval to use as the default in the preferences is: no value at all, make it dynamic. Compare the interval from the previous and current tablet events (in KisToolFreehandHelper::paint), and any time this interval is greater than the current stabilizer interval then increase the timer interval to be equal to or greater than that. In Dmitry's case the timer interval would've grown until reaching 50ms or more. The timer is stopped when the stroke ends, and when a new stroke begins the timer interval starts at some default value (16ms for example, or 1ms like 2.9.11 although that might be too fast). ----------------- Whatever is decided, I think something should be added to the interface (maybe in Configure Krita -> Tablet Preferences), like spinboxes to set timer values so that users don't have to go and modify 'kritarc' themselves, and be able to quickly test different values without having to restart the program. Someone above mentioned having difficulty doing that, for example. Regards.
(In reply to RN from comment #31) > Forcing the visual updates (what the delayed painter is doing) when the > window manager can't keep up with visual updates in the first place is not > going to give the expected result, it would stutter anyway. Don't mix window updates rate, tablet events rate and painting rate. They are three different things. Tablet events rate is the rate we get the tablet events from the driver. In normal situation the events come at rate 1 event per 7-14ms. Long window updates may delay the events and they will start coming in bunches 4-5 events per every 40-50ms. Then we have "painting rate", that is a rate we generate dabs with the stabilizer algorithm and pass them to the painting code. After passing the points to the painting code, the painting code paints and generates window updates, but the updates are not passed to the GPU directly. They first compressed to not overload the pipeline with too many small updates, and only after that are passed to the GPU (on GPUs supporting glFenceSync). This final flow of updates in "painting rate" and it cannot be higher than the GPU can handle. Basically, the flow looks like that: 1) Tablet events come in bunches every 7-50 ms. 2) KisStabilizedEventsSampler delays the flow by 50ms. That allows it to group the evens into 50ms groups and to adjust the time as if the events inside the group were flowing uniformly (e.g. for group of 5 events, the sampler will modify them as if they they were issues every 10ms). 3) These groups of events come to KisStabilizerDelayedPaintHelper, that regroups the groups from the sampler into groups of 20ms (20ms == 40fps, which should be enough for everyone(c)) and passes them to the painting code every 20 ms. Now I see that a thing that can happen is that delayed painter is not synchronized with the sampler. That is, it might happen that the delay helper can have "empty" cycles, where the samples from the sampler are not ready yet. To avoid the problem we should sync the timers of sampler and delay helper to be a multiple of each other. A quite test for this hypothesis might be to set: stabilizerSampleSize=60 stabilizerDelayedPaintInterval=20 That is still not very "sync", but if it makes the things better then we should move into this direction further. Probably, by merging the two timers into one. > In Dmitry's case the timer interval would've grown > until reaching 50ms or more. > The timer is stopped when the stroke ends, and when a new stroke begins the > timer interval starts at some default value (16ms for example, or 1ms like > 2.9.11 although that might be too fast). In feedback control systems theory it is called "proportional regulator". And it it really a bad thing to use, unless there is no other choice. What if the I accidentally have a delay of 200ms? Will all my further strokes be smoothed by 200ms? And if not, then we should do some PI-regulator, which is stable enough and still does the job. It may have quite a lot of unexpected consequences. > Whatever is decided, I think something should be added to the interface > (maybe in Configure Krita -> Tablet Preferences), like spinboxes to set > timer values so that users don't have to go and modify 'kritarc' themselves, > and be able to quickly test different values without having to restart the > program. Someone above mentioned having difficulty doing that, for example. > Regards. I have a feeling that there is some bug in how we handle the events flow. We should first try to fix it, instead of giving the user an option to control such non-obvious property. As a direction of further work, it might be a good idea to have a log of how many events are usually handled in KisStabilizerDelayedPaintHelper::stabilizerDelayedPaint() when isEndStroke is false. If the number of events is always the same, then my theory is probably not correct. If it interleaves with zero like "10,0,11,0,9,0...", then my theory is correct.
Sorry but I don't have enough time to dig into this for now. If someone wants to take this before I have the time again, please feel free to do that.
> I have a feeling that there is some bug in how we handle the events flow. We > should first try to fix it, instead of giving the user an option to control > such non-obvious property. > > As a direction of further work, it might be a good idea to have a log of how > many events are usually handled in > > KisStabilizerDelayedPaintHelper::stabilizerDelayedPaint() > > when isEndStroke is false. > > If the number of events is always the same, then my theory is probably not > correct. If it interleaves with zero like "10,0,11,0,9,0...", then my theory > is correct. I am taking a guess that the timer resolution may also affect the behaviour. IIRC it isn't using a high-resolution timer so maybe there is some fuzziness which depends on system load?
Git commit c083e1e1940f896e9bb19308694df72c95a9e00a by Alvin Wong. Committed on 10/07/2017 at 08:53. Pushed by alvinwong into branch 'master'. Improve framerate of stabilizer This change aims to improve the framerate of the stabilizer visual feedback. - Perform delayed paint during `KisToolFreehandHelper::paint` (pointer event) and use a timer for backup. - Removed the `stabilizerDelayedPaintInterval` config option. - Added the `stabilizerDelayedPaint` config option for disabling the delayed painting, Maniphest Tasks: T6440 Differential Revision: https://phabricator.kde.org/D6534 M +5 -5 libs/ui/kis_config.cc M +2 -2 libs/ui/kis_config.h M +34 -22 libs/ui/tool/KisStabilizerDelayedPaintHelper.cpp M +4 -2 libs/ui/tool/KisStabilizerDelayedPaintHelper.h M +8 -4 libs/ui/tool/kis_tool_freehand_helper.cpp https://commits.kde.org/krita/c083e1e1940f896e9bb19308694df72c95a9e00a
Git commit 3c1fefcaeca543a7d53c39a8126385ecb67a1809 by Alvin Wong. Committed on 10/07/2017 at 09:01. Pushed by alvinwong into branch 'krita/3.2'. Improve framerate of stabilizer This change aims to improve the framerate of the stabilizer visual feedback. - Perform delayed paint during `KisToolFreehandHelper::paint` (pointer event) and use a timer for backup. - Removed the `stabilizerDelayedPaintInterval` config option. - Added the `stabilizerDelayedPaint` config option for disabling the delayed painting, Maniphest Tasks: T6440 Differential Revision: https://phabricator.kde.org/D6534 M +5 -5 libs/ui/kis_config.cc M +2 -2 libs/ui/kis_config.h M +34 -22 libs/ui/tool/KisStabilizerDelayedPaintHelper.cpp M +4 -2 libs/ui/tool/KisStabilizerDelayedPaintHelper.h M +8 -4 libs/ui/tool/kis_tool_freehand_helper.cpp https://commits.kde.org/krita/3c1fefcaeca543a7d53c39a8126385ecb67a1809
I've updated the code, now it should render as smooth as other smoothing options. Please give this build a try and provide some feedback: http://scottpetrovic.com/krita/nightlies/windows/64bit/krita_master_64bit_a928de.zip (WARNING: Do *not* use this build for daily usage.) And here's a note after studying the behaviour of the timers under Windows... Please try not to set `stabilizerSampleSize` below 20 because this will cause some performance issues, and unless you really know what you're doing, do *not* use a value below 7, because not only does it waste CPU time, but it also cause the stabilizer to not work in the way it's supposed to.
If you are reading this, please test this build instead: https://ci.appveyor.com/api/buildjobs/t21lv3tn92vui8l6/artifacts/krita-x64-appveyor.zip There is one more improvement in this build (which unfortunately will not be included in the upcoming Krita 3.2 release).
Git commit fe3f85a849645de2158378a3f88efab9644b0686 by Alvin Wong. Committed on 31/07/2017 at 13:50. Pushed by alvinwong into branch 'krita/3.2'. Reduce copying in getStabilizedPaintInfo Since KisPaintInformation does heap allocation for private data, we really should try re-using when possible. Back-ported from 536565381cede0bf45dc082360e1008308edba57 on 'master' M +50 -0 libs/image/brushengine/kis_paint_information.cc M +7 -0 libs/image/brushengine/kis_paint_information.h M +2 -2 libs/ui/tool/kis_tool_freehand_helper.cpp https://commits.kde.org/krita/fe3f85a849645de2158378a3f88efab9644b0686
This bug has had its resolution changed, but accidentally has been left in NEEDSINFO status. I am thus closing this bug and setting the status as RESOLVED to reflect the resolution change.