OBSOLETE FOR NOW: Implementing a full rasterizer is too much work for now
KisPainter was created in the Qt 1.x days and modeled closely on QPainter. Since then, fashions have changed and KisPainter no longer looks as familiar as it once did to hackers. Besides, it doesn't supply us with everything we need to mangle pixels in a high-level way. (The low-level way is using iterators, writeBytes or setPixel, in order of desirability.)
Qt has split its painting system in three parts:
A QPaintDevice has a method that presents a QPaintEngine to a QPainter which then uses the QPaintEngine to change the pixels on the QPaintDevice.
Qt has various paint devices: raster, opengl, postscript, pdf. The raster paint engine paints on frame buffers: basically a 1d array of pixels.
The Krita equivalents are:
There clearly is duplication with the QPainter/KisPainter combo, but it is not apparent how to resolve that. Should we extend KisPaintEngine with everything necessary to paint with KisBrushes, KisPaintOps etc? Or Should we have two engines? Or should we keep the implementation inside KisPainter?
There are two possibilities for implementing KisPaintEngine: either write a native KisPaintDevice rasterizer for lines, painter paths and text (Qt uses Freetype here) or have KisPaintEngine first draw everything on a QImage and then use KisPainter to composite the QImage (after colorspace conversion!) on the target paint device.
The first is a lot of work and quite a maintenance burden, but can be much, much faster than the second option. We can also mix & match the approach: do the simple things directly, and the more complex things through QImage.
QPaintEngineState passes along the state of the QPainter to the paint engine. If we use an underlying QImage, we need to pass along the state to the QPainter we create on the QImage. This appears to be slightly complex and is definitely not what TT was thinking about when they created it.
Qt uses the basic porter-duff composite ops, while krita has a larger set of photoshop-inspired composite ops. The two sets overlap, but either set has options that are not present in the other set.
Selections and masks need to be honoured.
KisPaintEngine + QPainter should still create transactions for the Krita undo system.
In line with the design of Arthur and OpenGL, we should make KisPainter a state engine. That means: setters for things like paint ops, composite ops, colors etc, instead of parameters to all functions.
Needs to be possible, too! Maybe have a KisPainterState analogous to the QPaintEngineState?