I'm surprised not to have seen any discussion about this, as I have tested the 3.0 pre-alpha build 2 on both my desktop PC and a Surface Pro 4, and I'm finding the line quality to be, well... horrible. I can't draw a circle to save myself - there are straight lines amongst the curves and glitchy lines shooting off here and there, and while the results from the SP4 are not quite as bad, each stroke starts with something resembling a "tick", like it's taking a moment to get its act together before it catches up to the pen.

Are there conversations elsewhere about this that I've missed, or am I doing something unique that would cause both platforms to behave in this way?

Thanks!

(c:

I think what you are seeing is similar to this issue in bug tracker.
https://bugs.kde.org/show_bug.cgi?id=359171

Not much updates in the bug tracker, but I believe the issue is actively being looked at as "Fix tablet handling issues for Krita 3.0" task here:
https://phabricator.kde.org/T958

Thanks for the reply. I'm not sure if that's the same issue as I'm not getting those "hiccups" when drawing diagonal lines, but now I'm pretty sure it's related to this viewtopic.php?f=139&t=129526 - which I'm equally surprised at the lack of discussion about, since it personally renders Krita 3 unusable for me.

I don't know what's being processed in-between strokes now that wasn't in previous versions, but here's what it does to circles in a 7000 x 4500 16 bit image: https://www.dropbox.com/s/gzuf6d10bkxh7 ... .jpeg?dl=0

Well, the problem is a bit that we are all a little burned-out from the QT5 port and a lot of big changes happened, so we're not as snappy on bugs right now. In the case of the surface pro and other intel tablets, the more likely reason there's noone talking about this is because Intel shipped buggy drivers again, which means that most people just see a black screen when opening any version of Krita, and we're stuck with rewriting our whole OpenGL code AGAIN. And then there's the windows 10 updates hating wintab drivers which means that there's ton of people who do an update and suddenly their pressure sensitivity dissapears.

What you can do to help in regards to the line quality on the surface pro 4 is to record us a tablet log: Instructions here. (On the other hand, I am reading the IRC backlog and apparantly Smjert(one of the devs) seems to have something similar, also the second issue... Regardless, we could compare your tablet logs.)

Anyway, sorry if we seem silent, there's just a huge amount of rewriting going on to get past big issues.

Edit: As to what is being processed is that we now having a caching system in place that allows you to draw on a preview of the canvas when zooming out and thus have faster strokes with large brushes... It still needs polish, as you have experienced(though, thankfully, it got out of the stage where occasionally instead of caching it would just be crashing.)

That's entirely understandable, no need to stress. Considering the workarounds for the black canvas and pressure sensitivity bugs have been pretty well documented though, I'd have thought quite a few people would have bumped into this stroke glitches/interruptions issue by now. The silence surrounding it leads me to wonder whether it's something I've configured on both my systems that's out of the ordinary.

Is the Instant Preview Mode the caching system you're referring to, or is there another new system that's always working to speed up brushes? I don't have Instant Preview Mode turned on when the interruptions occur, and I haven't noticed any difference in speed compared to 2.x.

Whatever the case I'll send tablet logs and hope for the best. Is there an existing report I can add them to, or should I open a new one?

Thanks!

(c:

just make a new report.

might want to check this one first if it's similar: https://bugs.kde.org/show_bug.cgi?id=359561 Because I can confirm that one.

I can't see too much in common there, however I'm now seeing some slight evidence of the problem guruguru linked to above, so I thought it best to append my log files to that report. I think the processing interruptions might be a separate issue after all, so I've also made a separate report for that: https://bugs.kde.org/show_bug.cgi?id=359575