Krita/ActionPlan

Making Krita Ready

Krita has been under development for ten years now and is not yet ready for general usage. Discussions with artists it apears that it is not lack of features that is blocking wider usage but rather the following three issues:

• stability
• performance
• usability

One reason for these persistent issues is lack of manpower. The issue of stability is being tackled by the wider Krita team already. We want to tackle the other two issues with

Lukas Tvrdy, who has succesfully completed two summer of code assignments and is now finishing his thesis on brush engines for Krita at his university, is available full-time for three and a half months to work on performance and usability.

During the first part of his assignment Lukas will concentrate on performance, during the second part on implementing usability enhancements related to painting workflow.

In February, we will have a Krita sprint in Deventer, the Netherlands during which we will evaluate the first month of performance work by Lukas and prepare the usability work. Peter Sikking, the interaction designer who has been helping the GIMP team has offered to attend our meeting and help the krita team get started.

We will work in a scrum-like fashion with one week sprints with well defined goal:

Krita will be usable for creating art from scratch or scans on large high-bit depth, multi-layered canvases using the default brush engines.

(Extended compatibility with OpenEXR is also planned, though falls outside Lukas' goals, Cyrille Berger will take the lead here). Also see the Krita 2.2 Roadmap

The following concrete issues will be addressed:

• performance
  • optimization of the gbr/abr compatible brush engine: this will improve painting with large brushes
    • caching of masks (currently the largest performance block)
    • implementation of abr compability
  • optimization of the painting engine: this will improve working with images with complex layer stacks.
    • add caching to the iterators
  • optimization of the projection computation: this will improve working with large images.
    • add region-of-interest to the projection computation and investigate other bottlenecks.
    • optimize and debug the opengl-based canvas

• usability
  • focus on freehand painting:
    • brush selection: a more direct way to select brushes and control the most important brush settings.
    • color selection: direct access to most-used colors, recently-used colors, on-canvas colors and selection of colors related to the currently used color.

A preliminary timeline (to be updated with the outcome of sprint planning and results):

January

• week 3: profile krita using valgrind, oprofile and mutrace and prepare a report on performance bottlenecks. Setup a performance testing framework using QTestLib.
• week 4: implement basic caching for autobrush

February:

• week 5: implement advanced caching for the autobrush
• week 6: implement support for abr and vbr brush files.
• week 7: optimize pixel iterators through implementing agressive caching
• week 8: Krita sprint: evaluation of progress and interaction design

March

• week 9: During week 9, Lukas will be in Deventer, the Netherlands. We will work together on further performance improvements and do interaction design after the sprint. Lukas might visit the Blender team.
• week 10: optimization of the projection recalculationblending modes through vectorization

Start of usability improvements implementations

• week 11: mirroring of the canvas projection, possibly rotation
• week 12: color selection: canvas picker, recently-used colors
• week 13: implementation of several related-color selection mechanisms

April

• week 14: improved brush selection
• week 15: improved access to the most important brush settings
• week 16: add shear and freeform transformations to the transform tool
• week 17: session management: saving of active brush settings/colors in the session

During the project, we will release weekly reports of progress on krita.org.