Krita 2.0 -- A Technical Overview

This document describes the architecture of Krita for prospective developers and plugin writers. It is intended to become part of our manual, just like the plugin howto was part of the 1.x manual.

Note that while the architecture of Krita 2.0 is reasonably stable by now and development has gone into finish-the-features-release-the-bally-thing mode, the nature of software development, especially free and open source software development is such that documentation will of necessity lag behind a moving target. If you have questions not answered by this document or notice errors or anachronisms, please contact the Krita developers, either through our website, our mailing list or contact us on irc:

http://www.krita.org

kimageshop-devel@kde.org

#koffice on irc.freenode.org

(Historical note: Krita started life as KImageShop, was renamed to Krayon and then, for legal reasons, renamed again to Krita

Seagull's Overview

Krita is a raster graphics application built on the Qt, KDE and KOffice platform libraries. The design goals of Krita are as follows:

Krita depends on two essential KOffice libraries:

Most functionality in Krita is extensible through plugins:

(Note that the painterly framework plugin (krita/plugins/painterlyframework) is a meta-plugin that contains plugins of many types. Also note that brush-type plugins (as opposed to brush engine plugins) are a work-in-progress and part of research into making resource types plugins.)

Krita uses resources (as defined by the create project) suchs as patterns, gradients, brushes or icc profiles. The list of resources is a this moment fixed, but in the future it may become possible to write plugins to handle new types of resources.

Krita itself consists of two libraries: the core functionality in krita/image and the user interface in krita/ui. This document will first discuss the architecture of these fixed parts of Krita and then provide a hands-on introduction to each type of plugin.

The most important and central concept of Krita is that only colorspaces can interpret and change pixel data. Krita's paint device and tile system know nothing more than the size of a single pixel in bytes -- two bytes per pixel for a 8-bit/channel grayscale plus alpha colorspace, four bytes for 8bit/channel rgba, 8 bytes for 16bit/channel rgba -- and so on. To know what those bytes mean the colorspace is needed.

The Architecture of Krita: image and ui

KritaImage

KritaImage provides Krita with its core functionality: a paint system, paint devices, a plugin system to load various plugins, metadata support and code to handle several kinds of image manipulations such as transforms.

Paint Devices and Painters

A paint device (KisPaintDevice) is a rectangular area of pixels. A paint device is autoextending: it starts very small (64x64 pixels) and grows whenever pixels outside its original area are written to. A paint device has a certain colorspace, such as rgba, graya or laba.

You can change the contents of a paint device in four ways:

Tile System

koffice/krita/image/tiles

The tile system is the core of Krita. The tile system is responsible for:

Tile systems are not plugins: the overhead of calling virtual methods for all pixel access is prohibitive. There are currently two tile systems available: the 1.6 one (which is still default) and a new tile system that should give better performance and more thread-safety. In theory, it should be possible to develop a tile system that doesn't use tiles at all, but scanlines or a single memory buffer. However, implementing the autogrowing feature of paint devices when using scanlines or a single memory buffer would entail lots and lots of memory allocating and copying.

The current tile backends store image data in tiles of 64x64 pixels. The tiles can optionally be compressed when not used for some time and stored in a swap file when Krita is running out of memory. The undo system stores copies of entire tiles.

The main interface of the tile system is KisDataManager. Additionally, iterators and accessors are defined: kis_iterator.h and kis_random_accessor.h. Undo data is exposed through KisMemento.

Images and Nodes

Resources

Registries

Metadata

Pixel Processors

There are currently two types of pixel processors: filters and generators. Filters take input data and perform an algorithm on that data, generators perform an algorithm and write data.

Brush Engine

Undo handling

KritaUi

Resources

Resources are objects that can either be loaded from files in the file system or generated on the fly and that are available to the user. Examples are brushes, gradients or patterns.

KOffice-wide resources

Patterns

Gradients

Palettes

Standard resources

(gimp) brushes

Krita-specific resources

Brush engine presets

Filter settings

Generator settings

Scripts

Plugins

Colorspaces

Content objects

Tools

Brush Engines

Pixel Processors

Filters

Generators

User Interface Add-ons

Resource type plugins

Appendix 1. Changes Compared to Krita 1.6