Francisco Fernandes: A little understanding on Krita’s structure

This last thursday Boudwewijn schedule a skype chat group to present the main concepts of the Krita development. It was really nice, since a more dynamic interaction was made with the students. It answered some doubts I had and important features was explained. It covered from the KDE and Calligra foundation of Krita to dockers and resource management of the software.

I am posting here a few notes about what I got from it and some notes on how I imagine some of these will affect directly in my project. If any concept that I wrote here is wrong, please, leave a comment correcting me. This would be really helpful and more than welcome!

Color Management

I am familiar with color models concept, but not so familiar with color spaces. This was a good point in the presentation. It clarified to me that I do not have to worry about how to deal with these spaces since the color management libraries take care of it. Although I have some interest to understand how to manage colors, I think I will have to leave that for another time.

Tiles

Krita tiles was a really new concept to me. After you talk about the advantages of divide the pixels in groups, it makes sense and we question ourselves why we didn’t though about that before. Dmitry posted in the mail group a nice article about the Krita tiles. I believe I have to take some time to discuss this point with him. In my project I’ll deal with a considerable amount of particles so a full understaning on this framework will garantee a better performance of the brush. In one of the books I’m reading, a improvement in the grain interactions performance is done with the division of the space in tiles, although is suggested to divide the 2D region or in uniform Voronoi tiles or in a hexagonal grid. I think that in a general way, the effects are the same for the application, so the tile form doesn’t play a mean role.

Data Structure and Image composition

This was one of the trickiest definitions of the presentation. In a program like Krita, which have a big amount of processing and operations done at pixels, it’s expected that we should have a not so straightforward data structure.

The base class of the image components is the KisBaseNode class. It takes care of other nodes, layers and selections of the image. However this class do not have anything to do with its peers. For that, we use a KisNode, which is the parent class for Layers and Masks. Along with that, every node has a representation of it, which we call the Projection of that node. It’s a rendered result of the layer, with the processed data applied. For the composition of the final image result, a multithread structure is behind each node. Then to produce the result in the parent node, the setDirty method will pass through all the way up to it.

I don’t know if in the future I will need to modify or create a new layer type since the feeling of live sandpainting would need a lot of updates in the canvas. I asked that in the chat group and probably I will not need to do it. For instance, the closest feature in Krita that deals with this kind of painting is the Deform Brush. It modifies the closest pixels several times and updates the canvas after each mouse movement, so it’s more or less what I wanted.

Canvas and Tool Handling

The canvas take care of the user interaction through mouse, keyboard and tablet, paints the decorations and the visible image results. It has two implementations: one based on OpenGL and another based on QPainter. I had to look directly on the code to understand this better, but i think the main reason to have two implementations is that if the user have OpenGL on his/her computer, a better perfomance widget can be used. Otherwise, the QPainter based canvas will be used. Both classes inherit from KisAbstractCanvasWidget, so both has to have the same event handling.

When we modify something with a tool, the canvas have a Tool Proxy, which manages the current tool. So, when we change from some tool to another, the native events are mapped to the newly chosen tool. Then, when the tool does a operation, it requires a canvas update so the user can get the result.

Painting

I didn’t have much trouble to understand this point. Pentalis helped me a lot in this part. I even made a simple paintop modifying one of the paintops plugins in the source code. The Chalk Brush have a simple implementation and it was easy to understand the code and modify it. Most of my doubts in doing it was in the underlying structure, like how paint devices and layers worked together, but the presentation answered most of it.

Filters, Resources, Imports and Exports

These features wasn’t so hard to understand. Filters have the usual concept and is applyed in a multi-threaded stateless way. It is implemented as plugins in Krita. Imports and Exports use the KoFilter class as base of the implementation and invokes KoFilterChain to do the sequence of operations to complete the conversions. Resources are managed using KoResourceServer and manages resources of one type at a time. To represent the resource itself we use a KoResource as base class.

That’s it

This was what I got from the presentation. I have some notes about other questions that came after, but I believe that I have to write it with more visual details to a full undestanding about what I’m working on. My particle simulation didn’t work as I was expecting and I have to spend some time debugging it. Pentalis suggested that, after the simulation is working, I write the positions updates in QImages so we could have the visual feel of the particles moving. After that, I have to formulate how I will do this visual feeling in Krita, but I believe that with this brief background I will be able to do it.

See you later!