Krita bug-fixing

There are few Krita developers sponsored to work on Krita part-time and I’m one of them. It’s all donated by one man from Krita community, Silvio Grosso. Big thanks goes to him. Thanks to this initiative I can spend few hours a week on ugly Krita bugs. Besides that I’m still contributing to Krita as a hobby developer. Mostly by new features 😉 I blog after I finish milestone of 50 sponsored hours so here I go.

Some peaceful picture for a little too technical blog post

I started with bug 250978. It says, that stylus X/Y Tilt sensors are broken. Tilt comes from your (Wacom) tablet. I found out that the sensors were not broken, but tilt support, that artists except, is not about directly taking the values of tilt X and tilt Y from Qt event and use those, but you have to compute one value based on these tilts. The inspiration came from befriended project mypaint. The solution was to implement new sensors, namely declination and ascension. It is nicely described at mypaint wiki. Fixed and the outcome was happy artist.

Next bug was about the performance. Experimental paintop was kinda slooow and flickering. I had some discussions with Dmitry Kazakov, Krita developer, as he had some nice idea, but the idea is not general enough, but still might be worth to try to implement it, but later. Basically it is about the way we construct the shape of the experimental paintop. But it does not take into account the dynamic opacity of the whole shape or deformation of the shape. Flickering was fixed by trick similar to double buffering. I was rendering the shape directly into layer and then remove it fastly every brush dab. And the update algorithm of Krita flickered in that case. So now I render and remove the shape on the paintop’s internal device and it does not flicker anymore. I also improved the performance of the paintop by doing tricks when converting Qt’s QPainter polygon into Krita’s colorspace aware pixel buffers. David Revoy says he is happy with the speed of it, compared to Alchemy. I’m not happy yet as I have slower hardware as David, but I don’t have any idea how to improve it for now.

Then I investigated and worked on some smaller bugs. We had problems with our presets. We save XML into PNG file into metadata part. Because we save doubles (like 1.246) as strings, they were sometimes saved accourding the system locale. So in some countries like 1,246 and in some like 1.246. Then we load them with QString::toDouble(bool * ok) and we did not checked the ok value. Who does that? Have you ever checked printf() return code? We should checked it. We discovered the problem when Krita artist from Argentina send the presets to share them. I was not able to load them in English locale system. Some important preset values were zeros. So we fixed the loading with Sven by using mighty german locale when loading old presets if we fail. 1.246 and 1,246 are loaded ok in german locale. Now we save the presets without honoring the user’s locale settings. There might be some problems still present.

Then I investigated some slowness with paintops, but it lead to the pooler and that is maintained by Dmitry so I handed the bug to him. He successfully fixed it.

Rest of the time I spend with speedsensor bugs. I still did not nailed it. Basically I try to adopt mypaint solution with low-pass filtering on the speed computation. Maxy from mypaint was very helpful. Speed is computed now in the tool (was in the sensor itself) and will be computed even when you hover the canvas. The result is still not smooth speed, so I have to debug the code.

That’s it. Current plan is still bug fixing and making Krita more stable, faster and polished! I will continue in this work in my pace and I look forward to inform you after the next milestone!

5 Responses to Krita bug-fixing

Is anybody working on exporting to other formats? I didn’t do the report, ’cause I think that somebody already had did it; but when I export a drawing to PNG (for example) Krita exports only the ‘drawed’ area but not the entire page. Or, at least, there isn’t an option to do that. Also, sometimes it exports a cropped image by the top, for a few pixels…

“Then we load them with QString::toDouble(bool * ok) and we did not checked the ok value. Who does that?”

I do 😀 … and now I have a confirmation that this is a good practice, but it is a bit problematic since it adds some lines of code and the code could become a little less readable, but in the end it’s worth it