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: transactions, swapping and new fastBitBlt for tiled data manager

It was almost two weeks ago when I blogged last time. It was very tough those weeks because I had to merge two processes at the same time: preparations for an examination at the university and coding on Krita. But nevertheless, I'm glad announce much progress in my project for Krita!

Transactions refactoring

I've finally commited my patchset for transactions in Krita [1]. So now there is almost nothing common between Qt's QUndoCommand and Krita's KisTransaction (from the public side :)). It was needed to allow pooler (and upcoming swapper) threads to work efficiently. Now every transaction has the beginning and the end. So when you end a stroke on the canvas you finish a transaction as well. The pooler recognizes this signal and starts doing his routine job to optimize your next stroke (while you are still thinking about it ;)).

There are big changes from a developer point of view as well. Now you can create a transaction in a stack instead of a heap, that makes the code much simplier. And the most curious artefact of Krita's past was removed. There was a "global variable" in every KisDoc2 that used to disable saving undo information while loading the document. This variable had to be checked thoughout all the code of Krita: in every tool, in every action. Now it has gone. New tile engine does initial document loading in a cheap and fast way.

If you are interested in details of the new transactions system you can read a design document here. Examples are given!

Region() interface for paint devices

After finishing with transaction I continued my work on preparation to Filter API redesign. I've added a feature to a paint device for getting a QRegion of non-transparent (non-default) pixels. Of course it is based on tiles, and the region is rounded by 64. It is intended to be used as optimization of filter's application. You can read the details in Filter API Discussion Notes, that happend between Cyrille Berger and me in Deventer.

FastBitBlt interface for paint devices

This is part of Filter API redesign as well. The interface simply shares tiles between different paint devices. It allows us to create clones of devices really fast! It is intended to be used in layer merging subsystem and during filter application. There are limitation in this interface as well: it cannot be used when paint devices are shifted and when their color spaces do not coincide.

Framework for tile compression

After some discussion with Cyrille and his experiments with LZF algorithm, I started implementing tile compression framework inside the tile engine (Cyrille has already added nessecary features into KoStore to allow delegating compression to it). I'm going to kill two rabbits with one shoot, by doing this. The first "rabbit": Krita will be able to work with various formats of saved tiles. It means that we will be able to modernize the tile format without losing back compatibility. And the second: this framework will be the first stone in the swapper subsystem's building!

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

Creative Monday in Mocsow

We have just had three days of holidays in Russia. They were all due to a "prolonged" Labour Day. :)

On Sunday I was happily coding a Krita's [0] canvas system and almost done with the splitting [1], so I decided to get a day off and organize a "Creative Monday" on the next day. I went to the center of Moscow and got some photos [2].

Here you can see some results =)

[0] - http://www.krita.org/
[1] - http://wiki.koffice.org/index.php?title=Krita/KisCanvas2_Update_Split_Reasoning
[2] - http://maps.google.com/maps/ms?ie=UTF&msa=0&msid=107532280042317408794.000485c8770230c310ee3

About cars...






About windscreens...






About rice, fish, restaurant and abstractions...




And, of course, about love...