In krita alpha 3.0 alpha 2 (fa2b0d7) my paint strokes with my wacom bamboo touch tablet are less fluent (see url). It seems every segment of the strokes starts a bit offset from the previous. I compared it with mouse strokes, and with krita 2.9.6. Both give more fluent strokes. Reproducible: Always Steps to Reproduce: 1.Create image. (I tried 1024x1024 and 8192x8192) 2.Select a brush (I tried Bristle_Details and Ink-precision_03) 3. draw a diagonal stroke with your tablet. Actual Results: Strokes contain small hiccups in their position (very noticeable when using ink-precision-03) . For the bristle_details brush, the speed influences the width, so you also notice a width change at these hiccups. See the url for a comparison Expected Results: Strokes just as fluent as in 2.9.6 Windows 7 professional 64 bit Intel core i5-4670 CPU @ 3.4 Ghz 16 GB ram nvidia Geforce GTX 760 wacom bamboo pen&touch medium tablet
Created attachment 97104 [details] another hiccup example I too see hiccups happen in Krita 3.0 pre-alpha2 on my PC(Windows 10, dual screen, Intuos Pro 5) I attach my screenshot using ink-precision-03. I do not seem to be able to repro the issue with Krita2.9.11.
Hello jonathan, thanks for the report. It is sadly by itself a bit vague. What could really help us is if you made a tablet log: https://docs.krita.org/KritaFAQ#What_if_your_tablet_is_not_recognized_by_Krita.3F Attach that to this report and we get so much more information on what Krita thinks you tablet is doing so we can identify the issue.
Created attachment 97146 [details] Log of a diagonal zigzagging brushstroke, which results in the hiccups mentioned
Created attachment 97299 [details] Stroke glitches on desktop PC I experience a similar issue that afflicts both my desktop PC and Surface Pro 4. I don't have quite the same regular pattern of glitches, but there are occasional similar looking zig-zags when drawing straight lines. When drawing circles however, it manifests itself as more severe glitches as described and illustrated in the thread here: https://forum.kde.org/viewtopic.php?f=281&t=131138 . Attached is the desktop tablet log file, SP4 log to follow.
Created attachment 97300 [details] Stroke glitches on Surface Pro 4
Example image here: https://www.dropbox.com/s/gzuf6d10bkxh7fk/krita3_circles.jpeg?dl=0
Thanks guys! Considering there's two of you now, I'll set this to confirmed.
See also https://phabricator.kde.org/T958
with the latest windows build: 15:12:25 < guruguru> had a quick go. The pen stroke hiccup issue seems to be gone, for me. https://bugs.kde.org/show_bug.cgi?id=359171 15:12:26 < bugbot> KDE bug 359171 in krita (tablet support) "paint strokes with tablet less fluent than in 2.9.6" [Major,Confirmed: ] 15:12:37 <@boud> guruguru: cool!
In 3.0 Pre-alpha 3 this works fine for me. Thanks!
Thanks for checking!
I find this is much improved now, however there is still a slight glitch at the start of each stroke. When drawing fast circles this appears as a little hook on the SP4, and a short straight line on the desktop.
(In reply to Chris Jones from comment #12) > I find this is much improved now, however there is still a slight glitch at > the start of each stroke. When drawing fast circles this appears as a > little hook on the SP4, and a short straight line on the desktop. Hi Chris, if this is still happening in the next release would you be able to upload another tablet log? Also, what are your smoothing settings? Sometimes I get glitches when using weighted smoothing, while basic smoothing leaves my stroke intact.
Just the defaults with basic smoothing. I'll keep an eye out for the next build.
Created attachment 98313 [details] Stroke glitch in krita_x64_2.99.89.0 Still produces a little straight line at the start of fast curved strokes in krita_x64_2.99.89.0. Tablet log attached.
Hmm, it looks like in the tablet logs, there is a TabletPress followed by a TabletMove with identical coordinates. This may be disrupting the smoothing algorithm. 00000637 45.56365967 [5900] krita.tabletlog: "[ ] TabletPress btn: 1 btns: 1 pos: 507, 496 gpos: 545, 580 hires: 544.924, 580.409 00000638 45.56517029 [5900] krita.tabletlog: "[ ] TabletMove btn: 0 btns: 1 pos: 507, 496 gpos: 545, 580 hires: 544.924, 580.409
It actually seems to be worse with the mingw build I posted yesterday: http://valdyas.org/~boud/krita-3.0-Alpha-master-d236382-x64.zip With that build on an SP3 I can hardly get any smooth lines, I'm not sure why yet...
And that seems to be because we need to patch Qt, I'm making a new build with a patched Qt 5.6
Try drawing in full-screen mode to see if the problem still occurs.
There's still a short straight line at the start of strokes in normal and full-screen mode in krita-3.0-Beta-master-962bfe1-x64
Hi, Chris! Could you please try the latest version from this link http://files.kde.org/krita/3/windows/devbuilds/krita-3.0-da5496d-x64.zip and, if the problem is still actual: 1) Activate Basic Smoothing 2) Activate tablet events logging 3) Start video recording your screen with some software Then try to reproduce the problem a couple of times I need the following data: 1) Video of the bug 2) Tablet log for this video
Created attachment 99307 [details] Stroke start glitches in krita-3.0-da5496d-x64 Hi Dmitry, Here are videos and logs of both my desktop PC and Surface Pro 4. An interesting new finding is that the Surface often produces a double-start to the stroke when OpenGL is enabled, along with a slight hook. Without OpenGL it just produces the hook. I've only noticed this now because normally I'm having to use the SP4 without OpenGL due to a stuttering issue (https://bugs.kde.org/show_bug.cgi?id=360588), and it's possible this is exacerbating the problem and causing the double-strokes. My desktop also displays similar stuttering when using High Quality filtering (https://bugs.kde.org/show_bug.cgi?id=331794), but doesn't produce double-strokes with other scaling modes or with OpenGL off though. Incidentally I've used CamStudio to record the videos and it's possible you'll need the CamStudioCodec to view them... let me know if you have playback problems and I'll try something else. Hope that helps!
Hi, Chris! I have just tested my tablet devices on Linux and Windows with OpenGL on and off and I still couldn't reproduce the problem. I have a feeling that the problem was related to a bug in Qt 5.6, where the tablet events got compressed accidentally. The bug was in a wild until we started to patch Qt, shipped with Krita. Now the bug should be gone. Could you please check if the bug is still actual for your hardware on Krita 3.1.3rc1? https://download.kde.org/unstable/krita/3.1.3-rc.1/krita-3.1.3-rc.2-x64.zip If you still can reproduce the bug, please reopen the bug.
*** Bug 360588 has been marked as a duplicate of this bug. ***
Just wanted to add that I also tried to reproduce the Speed sensor problem and I couldn't reproduce it either.
Hi Dmitri, On the desktop the straight line "hook" at the start of a stroke is about the same as in my video attachment in Comment 22. However, I find that Sketchpad (built into Windows 10) as well as OneNote also display the same issue to about the same degree. Krita on the SP4 is also producing similar results as in the SP4 video, but without the double stroke start. Sketchpad and OneNote on the SP4 however do not show signs of the hook issue, so I'm not sure what to make of that.
It might be somehow related to the driver or the driver version... Probably, we should use Windows Ink for that... Is it possible to update a driver for your tablet-screen?
Hmm, not sure... as far as I know Windows Update takes care of driver updates on the Surface, and it's up to date in that respect.
Hi Chris, may I ask if this is fixed by enabling Pointer Input (Windows Ink) in the more recent versions of Krita?
Hi Alvin, In 3.3.3 there's no difference in the stroke start glitch when changing from WinTab to Pointer Input. When using the Dynamic Brush it's about on par with native Windows Ink apps that are built into Windows 10 though, which I assume means those apps are also dampening the effect with some kind of smoothing algorithm, and it's probably not going to get much better in Krita on Win 10 anyway.
Thanks. This would really appear to be an issue with the driver. I'm afraid there aren't anything to be done in Krita.