What makes Krita's canvas operations feel so "wrong"?

Develop Artists Feedback & Testing
21

I wonder all the time if that’s why you draw or paint worse pictures?
Krita is for me a painting and drawing program, one with which you can now also create animations.

But if there are small - for me on my old graphics workstation (2x Xeon CPU’s & 96 GB, SSD’s and ex-upper class graphics) by the way not noticeable - jerks or stutters, while I rotate, zoom, pan, does not change how I then paint, right? (I have now tested 30 minutes. I’ve rotated, zoomed, panned, I don’t see or feel any stuttering).
Do any of your tests affect the images or animations that end up, and if so, where or how?

If it were about the control of a military combat drone, which cost innocent people their lives or health in case of a not 100% control, then I could understand all this effort. But this is far beyond my comprehension, none of your tests are about “putting a line on paper” and that is the purpose of a program like Krita - to paint.

Michelist

22

I think that all this has more to do with ergonomics, although let’s say that for many it is not relevant, in the eyes of others it is uncomfortable and that feeling can affect work flow a bit.

4 Likes
23

I wonder all the time if that’s why you draw or paint worse pictures?

I’m going to assume that’s a translation error and not an attempt to harass me.

Krita is for me a painting and drawing program

Likewise, but the methods of which we accomplish that are much different. I personally pan/tilt/zoom around the canvas more often than I actually put lines down, and at extremely high speeds.

2x Xeon CPU’s & 96 GB, SSD’s and ex-upper class graphics

These are below my specs and I still get the issue, and you likely do too. If you paid attention to my explanations in the thread you’d realize this isn’t a hardware speed issue.

does not change how I then paint, right?

There are a lot of things about the program that ‘don’t change how you paint’. If Krita took 10 minutes to save every time you finished a painting, I’d consider that something worth fixing, but your same argument could be used against fixing that.
This is also a very strange argument coming from you as not too long ago, you suffered from a bug that “doesn’t impede the ability to draw”. Yet you still want it fixed, weird.
Your bug also only affects you and you alone for right now, my bug affects, whether they notice it or not, whether they care or not, nearly every artist on the platform.

Second, you’re assuming that this bug only affects people who are already using Krita as their primary program. As I stated in the original post, this bug has prevented me from recruiting another artist to the platform already, and my main desire for fixing it is because of that. I’ve already put up with it for 2 years and have likely used the program over 1000 hours with it, so it’s not about me, it’s for the program as a whole. How it presents itself to new artists.

Do any of your tests affect the images or animations that end up, and if so, where or how?

This is also a terrible pretense in which to judge the usefulness of a bugfix. People can paint beautiful landscapes in MS Paint, that doesn’t make Paint a ‘good program for artists’.

If it were about the control of a military combat drone, which cost innocent people their lives or health in case of a not 100% control, then I could understand all this effort.

This is a strawman, and you’re not even the one putting in the effort. Why do you care if I ‘put in effort’ to make the program better? It almost sounds like you’re against improvement of anything that doesn’t directly benefit you.

none of your tests are about “putting a line on paper” and that is the purpose of a program like Krita - to paint.

The purpose of Krita is to be a group project making a program that artists feel they can create whatever they feel like in easily and efficiently. The actual act of drawing itself is part of that, yes, but there is much, much more to Krita than just ‘putting a line on paper’. Usability is it’s own bug category in the bug tracker for a reason.

4 Likes
24

Hi @Michelist @Ralek , it sounds a bit confrontational now, please do not continue talking with that tone if possible. We all have the same goal here, no need to get all worked up. I doubt either of you had bad intentions here, in any case. You can go read KDE’s Code of Conduct, it’s very pragmatic and it shows nicely what are the pillars of the community. See KDE Community Code of Conduct - KDE Community

Note that both posting about an issue that might look unimportant to some, but is an issue to the person in question, is very much allowed (you never know if other people experience it as well or have an issue with it), and at the same time, saying that in your opinion it’s not really a big issue is allowed as well. It just needs to be done in a respectful way, that’s all. The purpose of discussions is to learn about the perspective of others.

2 Likes
25

I don’t think it is a confrontation. For me it is not, and should never be. It has to do with translation, and I am writing my answer at this moment, but I’m slow with long text. Please wait a few minutes.

Michelist

1 Like
26

@SchrodingerCat: I can’t deny that it may feel unattractive to some and the others don’t care. Yes, it is a question of everyone’s own viewpoint.
I wanted to express that zooming, rotating, moving does not change the result, the picture that is painted. The feeling is always such a thing.
I have experienced on my former PC that lack of performance often makes using Krita not very enjoyable, but with reasonably powerful hardware, I find it amazingly fast, I just don’t see that judder.
But maybe I am already too old, and my senses are rusty.

@Ralek: To clarify this: Far be it from me to harass you.
It is a translation problem. It has to do with the fact that the English word “you” can stand for one person as well as for several people. And this question was whether someone would paint badly because of a problem in zooming, shifting, rotating, and the skills as an artist do not depend on these things.
And I was totally surprised in the first moment when I read that I should have bothered you. Sorry for this translation problem.
And I do not know any of your works, so I am not able to comment your abilities as an artist in no way. Perhaps I have seen one, but not knowingly.

###########
And now just a short answer to not everything by far.

I think it has a lot to do with each individual. I did write that this is hard for me to grasp.

What I just really liked is your pointing out the “comfort error” I described with the “expanding spacers”, from that you can see that there are things that are more important to one than the other, thanks for bringing that to my attention, I was blind on that eye. (And I had to laugh at myself).
But I do not suffer from it nor did I suffer from it, I just posted, just like you did in this Topic, my observation.
…
And what you are absolutely right about is that it is of course very annoying to have to wait minutes for a save operation to finish on large files. I use Krita privately, so time is not an issue, but for someone who makes a living with Krita, this is not acceptable.
…
And now I would like to finish my answer. I would like to leave it at that, unless you insist that I answer your answer passage by passage, then I would ask you to be patient until tomorrow. If you have also read my last posts in the topic you picked out, you will know that I am limited in my abilities because of my strokes.

Michelist

1 Like
27

There’s no need to respond passage by passage, your feedback and consideration is valuable and I understand your stance even if it is a counterpoint.

I work with many Russian artists in my line of work and I personally have been the victim of poor translations hurting people. As such I understand your frustration and I fully believe you meant no harm in your message

I’m sorry that my messages came off as confrontational, I prefer to be concise with my reasoning and hold strong beliefs for what I feel would be beneficial for others. It’s that same method of thought that I believe causes this seemingly small bug to be such a problem with me after seeing it cause a friend pain personally.

To keep things on topic and update people who feel the same way as me toward the main topic, I have been in contact with a friend of mine who has experience with KDE/QT to get back to me on a quote for implementing a triage and a fix for this issue. In the meantime, I’ve also taken it upon myself to attempt to triage it in my off time, taking my first dive into the code base itself.

1 Like
28

With all due respect, in that case we all can just use ms paint. Or anything offers only the bare of the bare minimum without any performance/functional optimizations.

29

I think the use of MS Paint would affect the result - the picture painted.

Michelist

30

Honestly, I do feel somewhat slow the movement of the canvas in Krita, I thought it was only my thing but seeing this post I may not be the only one who feels that way.

Still I really love using Krita :heart:

3 Likes
31

So I’ve taken a dive into this issue, and it’s much deeper than previously expected.

The first major problem I ran into is that Krita’s timings are not defined by any sort of internal clock or pattern, its timings are purely event based. Each time QT senses a mouse drag with the pan tool, it updates the canvas position. This could be halfway through a frame, it could be a millisecond before the next, it could be right after the frame was already output to the monitor. This is what is causing the stuttering.

I tried multiple ways of solving the issue. Some didn’t work, some kind of worked. The closest I got was a method that:
Set a timer while the pan tool was being dragged, where every 17 ms (~60fps), an event would be sent to trigger an update of the canvas position while dragging. This new position was not calculated directly from the previous positions, but rather as a difference between the last update and a new, calculated position taken from the timings of the last 2 ‘true’ mouse positions and a theoretical calculated third mouse position.

This partially worked, but introduced a noticeable stutter on average about twice a second that was the result of 2 things.
The first was that the calculation time for a new frame draw is not insignificant, and my modification didn’t account for that.
The second is that I was updating the output once every 17ms, while a true 60fps screen updates about once every 16.67 milliseconds, and I’m not versed enough in C++ to find a more accurate method of timing these.

Until I discover, or a method is created in QT/KDE that allows for me to listen to frame buffer output events in the OpenGL rendering pipeline, I fear there may not be an easy solution to this.

I’ll be giving it another shot in the coming days but I wanted to report back in the meantime.

1 Like
32

Well I have noticed this for a long while now but honestly is not something that has worried me the least bit.

To my experience when the artist picks something like frame rate as a reason not to change… Well it is because they don’t want to change even before you show whatever it is. Artists are annoying as hell out of their comfort pick. And that was probably the first issue they saw different that honestly speaking I classify it as a luxury feature.

For me dropping frames is acceptable if it means that it keeps up with my actions. Now “if” fixing this means going slower just to show everything. That to me is a way bigger issue and reason I rather have frames dropped.

33

I completely agree, I’d much rather have lower latency than smoother panning, but a ‘true’, native fix for this would actually not affect latency at all, if not improve it.

Tangentially related, the first thing I tell new artists to do is disable v-sync and triple buffering for Krita in their Nvidia settings manually. These are on by default for Krita. Not ‘fast’, not ‘adaptive’, off entirely. That lowers the input latency by almost 70 ms on average, which is extremely noticeable for even the most uncaring artists.

I considered making a bug report to see if there’s a way Krita can disable VSync for itself, so I don’t have to pre-warn every artist I suggest the program to that “I swear it’s not usually that delayed, you just have to tweak some settings for NVidia”

5 Likes