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:

- Enable the user to work with layered raster graphics of any sizei
- Enable the user to create original art
- Enable the user to work in any colorspace
- Be flexible and extensible for developers
- Be fun to hack on for developers

Krita depends on two essential KOffice libraries:

- Pigment (koffice/libs/pigment): handles colorspaces
- Flake (koffice/libs/flake): handles tools and user interaction and integrates fine-grained objects such as vector graphics or rich text in Krita.

Most functionality in Krita is extensible through plugins:

- Colorspaces (through pigment): for example, grayscale, rgb, lms, cmyk, lab, xyz
- Content objects (through flake): for example: text, vector, charts
- Tools (krita/plugins/tools): for example: freehand filter, select-by-color, fill tool
- Brush engines (krita/plugins/paintops): for example: soft brush, chinese brush, smudge
- Filters (krita/plugins/filters): for example: sharpen, unsharp mask
- Generators (krita/plugins/generators): for example: fractal, solid color, pattern
- User interface additions (krita/plugins/viewplugins): for example: rescale, scripting

(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:

- By reading bytes in from a .kra file: KisPaintDevice::read()
- By reading in a chunk of memory that can be interpreted as pixels: KisPaintDevice::fill() or KisPaintDevice::readBytes()
- By opening a non-const iterator or accessor: KisPaintDevice::createRectIterator() and similar
- Through KisPainter, KisFillPainter, KisGradientPainter or KisConvolutionPainter (these use iterators/accessors themselves

### Tile System

`koffice/krita/image/tiles`

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

- storing the pixel data of a paint device in memory or in a swap file if memory is being exhausted.
- retrieving the pixel data of a paint device
- store undo data for a paint device

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