Krita: panning, race conditions and other bug fixes

Hi, All!

I haven't been blogging for about three weeks. They were quite tough. Like everyone in Krita team I was working on fixing bugs and making Krita user ready. And now I'm going to describe what I've done.

The first week was spent on making Panning and Color-picking gestures work for all the tools. I achieved this by moving gestures code to base classes KisTool and KisToolPaint. It was quite non-trivial task, because I had to fix classes of all the tools in Krita as there is no common strategy how to handle mouse events.

I think, we should elaborate some good system for gestures after 2.3 release, but I can't really imagine how. This new system must handle all the mouse and tablet events itself, and provide some callbacks(?) and interfaces for tools. The callbacks should look like: startStroke(), cancelStroke(), endStroke(). The problem is, our tools use different interaction types. I mean not all of them use "strokes" strategy. For example, Paint Bucket tool uses single clicks, Gradient tool uses dragging, Path tool has a very complicated system with various types of clicks and modifiers. I think, we need to incorporate "strategy" pattern here, but I really can't get it how.

The next week I was fixing various bugs. I fixed selections of masks and filters, so now they are applied to the entire layer, not just to a small rectangle in the bounds of the image. Then I fixed a race condition in KisUpdaterContext. It used to rely on KisSharedPtr in concurrent environment heavily. But the shared pointer do not have many guarantees for multithreading. So I created a very convenient environment for the shared pointer with only one producer and one consumer. It can easily handle it. After that I fixed a race between KisGroupLayer and KisAsyncMerger. Then Color Conversion Curves Filter was fixed. The problem was really tricky here. It was due to the use of temporarily copied QVector, returned form the function. When we performed data() call, Qt made a deep copy of the vector and deleted the temporary object very soon. So the code used to read free'd memory. The problem was solved by using constData() instead to avoid copying.

And the last week was spent on fixing race conditions inside the data manager. They were really difficult races to find. You can read very detailed report about them in my commit message [0].

[0] - http://websvn.kde.org/?view=revision&revision=1181593

Krita: Free Scrolling and Masks improvements

Hi, All!

Last week I was working on fixing one of the most reported bugs of Krita. Many users wanted to scroll the canvas in a way to see corners of the image in the center of the screen. Now it is easily possible. More than that, coupled with the ability to zoom and pan image with the wheel, Free Scrolling makes the workflow very smooth. I think people who ever used CAD systems would feel something like deja vu, when try it ;)

Another task of mine was to fix Masks updates, because they curiously broke after i activated multithreading. I've spent about 9 hours searching race conditions and all, but the problem appeared to be trivial. There was a legacy code that wasn't ported when move() feature of paint device appeared. It caused clear() operations clear wrong areas. Everything was fine in single-threaded environment, because those areas were overwritten immediately. But in multithreaded case, those operations broke usage-guarantees of the data manager (that is we must not access intersecting areas simultaneously, but must work with independent areas instead). Broken guarantees, in their turn, led to race conditions during update. You can see how trivial the fix was [1], but it was really tough to find :)

[1] - http://websvn.kde.org/?view=revision&revision=1174365

Krita: New Transaction System For Review

Today the new API for transactions has been finished!

It turned out that Krita can't fully rely on QUndoCommand functionality, so on Deventer sprint it was suggested to modify our transactions [1]. Now I'm glad to show you results of the work done.

Shortly, the new system is based on two classes, the first represents the boundaries of the transaction, while the second defines the lifetime of the undo information. Touching base transaction classes caused much code to be revised, but now it is done.

So now, if you want to get more details about new system, you can read a complete description on our wiki page.

You can even take part in testing of the new system by applying the patch.

[1] - http://wiki.koffice.org/index.php?title=Krita/Filter_API_Discussion_Notes

Krita: canvas will not flicker anymore!

Many have already seen this annoying bug in Krita canvas update system. It was seen when you painted with big and complex brushes like Hairy Brush on a multilayer image. Now I'm glad to announce that the patch is produced! And it will be in trunk soon!
The bug was caused by a race condition between Image and UI threads. The latter one tried to read the data from the merged projection while the former one was preparing it. I have fixed this by splitting the update process into two parts. The first part reads data from the image. It is executed in the context of the Image thread. Then the thread saves update information got from the canvas to the external structure called KisUpdateInformation and passes it to the UI thread, that continues updating doing rescaling and other slow operations.

This patch touches much code in canvas subsystem, so there will be a short delay for reviewing and testing the patch. And if you want to see it in trunk faster, you can help testing it! [0]

There are some technical details of implementation in our wiki [1]

[0] - http://dimula73.narod.ru/canvas-split-single-v2.patch
[1] - http://wiki.koffice.org/index.php?title=Krita/KisCanvas2_Update_Split_Reasoning