Archive for the ‘Krita’ Category

Comparing Krita packaging size

December 17, 2016

Every time a new version of Krita is released I see somewhere a post where someone lists the output of their distribtion package manager and complains about the number of dependencies and the installation size. In the past dependencies used to be a huge problem where the connections between the packages causes a chains of dependencies at which end you e.g.  needed install a MySQL server.

Since the arrival of KDE Frameworks the dependencies between the packages were reorganized which in theory should reduce the required dependencies and installation size. So I wanted to find out how different distributions handled it and if there is really a reduction.

For the experiment I installed several distributions in VirtualBox and checked how many packages they would install for the distributions default Krita installation and how big the installation size would be. For each distribution I used the latest available 64-bit version. I picked distributions with deb, rpm and arch packing to get a few different approaches to the problem. To simulate the maximum dependency case I used only desktops that are based on GTK.

Below is the data I gathered.

Still packing Krita 2.9:

Ubuntu 16.10

  • Packages: 175
  • Installation size: 488 MB

Mint 18.1 Cinnamon

  • Packages: 115
  • Installation size: 374 MB

At the time of testing Ubuntu and Mint still delivered Krita 2.9 based on Qt 4 despite 3.0 being out for several months. For some reason Krita package does have still have dependencies on KDE Frameworks 5 and Qt 5. Beside that Ubuntu does also install a complete Ruby development environment.

I also looked at Debian 8.6 which still features Krita 2.8.5 with an 138 package and 414 MB installation size. However the packages are so outdated that they can’t be compared to the current ones.

Krita 3.0:

Manjaro XFCE Edition (16.10.3)

  • Packages: 38
  • Installation size: 211 MB

OpenSUSE Leap 42.2 with GNOME installed

  • Packages: 69
  • Installation size: 163 MB

Fedora 25

  • Packages: 59
  • Installation size: 226 MB

Not very surprising here is that the number of installed packages and installation size is quite low. OpenSUSE may already have some bits installed which could explain the slightly lower installation size. All three have very clean dependencies without anything from Qt 4 times. There are very little dependency chains with KIO and it’s dependencies being the biggest one.

In comparion the Krita 2.9 installation from Fedora 24 has 66 packages and 308 MB installation size. A Krita 3.o installation without any new KDE Frameworks and Qt 5 packages on KDE Neon comes in at 96 MB installation size.


KDE Frameworks actually reduces Krita dependencies and installation size on non-KDE systems significantly. Factoring out the net installtion size of Krita, the dependency size almost halfed compared to Qt 4 times. Even on smaller currently sold storage devices the installation should take less than 1% of the storage capacity, so it’s practically not an issue anymore.

Packaging on Ubuntu-based distribution appears to be a mess at the moment. If you are using these distributions and want a recent Krita without tons of dependencies I would recommend looking at the Snap or the Appimage which already delivers Krita 3.1.

Even on the other distributions the Appimage is a serious alternative if you only want to run the newest Krita.

If you use another distribution feel free to post the numbers in the comments. I wonder if some distribution does a much better or worse job.

Krita Sprint 2016

September 3, 2016

Last weekend I attended this years Krita Sprint. It was once again taking place in Deventer. This was my third Krita Sprint in Deventer and as usual the sprint was really great. With every sprint there are a lot of new team members that you meet and also some that you have known for several years.

I arrived on Friday evening (a lot later than anticipated due to an airconditioning failure on the train to Deventer). Due to the heat outside the whole team was in the basement of the church under Boudwijns house. There was no heat or daylight and this time even WLAN access, so perfect hacking conditions. I spent most of the evening catching up the stuff that already been discussed. After luch I did some hacking on the remote control. I also added some functionality to make it possible to pick the correct internal color from the canvas from the new color dialog.

On Saturday we had lots of discussions about various topics. I demonstrated the early stage of my remote control experiment. With remote control it’s possible to export properties of Krita as variables that other applications or devices can access. As protocol it currently uses OPC UA using the implementation from Open62541, which allows to use variables and methods to be used over the network. For now it does support changing brush size, opacity and flow.

We had some discussion of the organization of bugs and features and the way they go from brainstorming to final release. In the beginning this was mostly by one developer who picked up a task and developed it. Now we have a lot more people with different interests working on Krita so the development of a feature is a lot more distributed than it used to be. New features are running through different phases from brainstorming to UI design to development to testing and finally documenting and release. Now that 3.0 is out, the next Krita releases will be coming out much faster and more incrementally.

We had a discussion about the future of the resource framework. Resources used to be a small part of Krita with just a couple of brushes, gradient and patterns. Over time it was extended again and again to adjust it to upcoming requirements. We added brush presets, workspaces, palettes, bundles are most stuff. On top a tagging system was implemented. There used to be only a few resources, but now you can have a big collection and Krita still loads everything at startup which causes a long startup time and use more memory. We discussed using database to cache a preview of the resources and manage the resources. However this is a very complicated problem so it will need further planning and a lot of development.

The biggest discussion on Saturday was about the vector graphics improvements that are coming to Krita. Krita used to have vector graphics integration since 2.0, but it used to come out of the productivity applications world which had a couple of downsides for Krita. The vector graphics part was integrated on a low level, but in the user interface there is currently still a disconnect between the pixel and vector world. For example the way you pick a color is different when you have a vector graphics selected. The plan is to unify that and make the transition more seamless. Beside that we also discussed how we the Krita brush engines could be extended into the vector world. As part of the vector work I took over the stop-based gradient editor which is currently undergoing UI design.

A lot of the discussions and more bugfixing continued until I had to leave again on Sunday afternoon. I want to thank Boud and Irina for organizing the sprint and KDE e.v and Krita foundation and all the community members for supporting us.





11 years developing Krita

December 27, 2014

This post was orignally planned as my 10 year anniversary post, but due to me finishing my thesis and starting on my new job this got a bit delayed and now I’m already 11 years on the Krita team. Boudewijn has already posted a much more detailed look back at the history of Krita. Here just some of my thoughts on the last 11 years.

I started working on Krita in late December 2003.  The funny thing is that I’m not an artist and I don’t really have a use for the application itself and was more interested in the development of a graphics manipulation in general. Ironically my art teacher back then claimed that you could not do art with the computer because there was not direct connection between the hand and the canvas and therefore the machine had more influence than the artist.

Back in 2003 Krita had never been released and the application was only able to do some very crude painting. I think the main reason that I started contributing to Krita back then was that I was much more comfortable with the single window UI and the fact that it used Qt/KDE and C++. In the early days I would never have imagined that I would be still with the project after 10+ years and how big the project is now. Even that the project exists today is a miracle and result of many developers putting in effort without ever knowing how it would develop. For the first few years we had almost no users and the users that we had were die-hard KDE users. At the time that wasn’t a bad thing as it allowed us to do some radical changes and experiments. Many features that were developed during this time still provide the base for the current Krita.

The early days of development were a bumpy ride. We made three releases based on Qt/KDE 3 and Krita was starting to take of with version 1.6. Then we made the jump to KDE 4, which was expected to be big, but in hindsight turn out much bigger than anyone was expecting. In the end it took several years to complete that and if we had known how long it would take we wouldn’t even have started that. During that period the project the suffered quite a bit as development stalled for some time and we lost some developers which got exhausted from the port. The biggest things we learned from that is to never start porting to a new set of libraries before it’s even tested,  to never make a release cycle longer than a couple of months and when you are porting to never do anything but porting.

After Krita 2.0 was released we got back on track and made good progress. Releases happened much more frequently still the improvement from version to version became bigger and bigger. Looking back it’s interesting how old even the last version looks. One of the major turning points in this time was the decision to concentrate on painting in Krita. Back then it was a big controversy, but today I think it was maybe the best desision we ever made. It sharpened the development and made Krita overall a better application. I think we proved the everybody wrong who said that we focus on a too small user group. Based on bug tracker and forum activity we certainly have at least a tenfold growth of the userbase since then.

The current development of version 2.9 is really exciting. This version will bring support for multiple-windows inside the application which is one of the biggest changes we ever made to the user interface. Also really nice it that the 2.9 beta is attracting a lot of user testing. Several years ago I made a post about Krita needing more bug reports, now we got in the last two weeks more bug reports for the 2.9 beta than we got in a whole year back then.



For the future there is a lot of interesting stuff coming up. Due to my new job I won’t be able to contribute as much as I used to, but I will continue to work on Krita. After 2.9 we will make the jump to Krita 3.0 which will use Qt 5/KDE Frameworks 5. The new libraries are not that interesting I think as in terms of desktop development not much changed since the  KDE 3 days. For some users it will mean less dependencies which will certainly close some discussions. I think the developments I’m looking forward to in 2015 are Level of Detail painting (which should bring us up to Photoshop speed) and animation support which is one of the most requested features. Both have already seen some initial development, but will need more work in 2015.

I want to thank every developer who ever worked on Krita and all the users who supported us.

Krita Sprint 2014

May 31, 2014

Last but not least, here is my report from the Krita 2014 sprint. It was the fourth Krita sprint and the first one since the previous sprint 2011. In terms of Krita development that a really long time and quite a lot happened since then. After the last sprint in Amsterdam the sprint location was once again in Deventer. As usual the sprint was again very productive and generally fantastic with lots of old faces and some new ones.

Most of the discussion was around planning for the next two versions which will be 2.9 and 3.0. With 3.0 we will make the step to Qt 5/Frameworks 5 so 2.9 will be used to finish all the ongoing development to make a clean port. We learned a lot from KDE 4 in this regard and this time we will port a lot later and also won’t don’t any other changes beside the port. Due to the upcoming port Krita 2.9 will be one of our most ambitious releases ever. The biggest new feature will certainly be that Krita will be able to handle multiple images in the same window. There is also a fundraiser in preparation to push the release even more.

After the main sprint concluded I workde on some problems the artists pointed out. The screenshot below shows some of the improvements that I made as a result of suggestions during the sprint.

Some results of the sprint


The smoothing setting in the tool options is now a button group instead of a combobox, which makes switching between different modes much faster. The composition docker now has checkboxes to control which compositions will be exported. It also now possible to update a composition after it was created and rename it. The gradient editor has seen some enhancements. It’s now possible to add new gradients and edit existing ones. The layout of the editor itself it also better now.

Many thanks go to Boudewijn and Irina for the excellent hosting and to KDE e.V. for making the sprint possible.

How to fix Krita on Ubuntu

March 16, 2013

We recently had a lot of problems with Krita running on Ubuntu. So here is the up-to-date of list of things that you can do to fix your Krita experience on Ubuntu.

  1. Use proprietary graphics drivers. As I pointed out before there are some problems with LLVM and the drivers, which haven’t been fixed so far.
  2. Remove the qt-at-spi package The something broken with the package that causes crashes in the save dialog in some applications (bug here).
  3. Change the theme. The default theme Ubuntu uses for Qt applications is broken. Plastique and Oxygen themes are working better.

Calligra Sprint 2013

March 16, 2013

Last weekend I have been taking part in this years Calligra sprint, which once again was at the Linuxhotel in Essen. This year we had something special as the sprint was actually happening in two places at the same time. While one part of the team was in Essen, the other part of the team meet in Bangalore. This was simply due to the problem that we could only fly a limited number of people around the globe. Both meetings were connected via Google Hangout which worked reasonably well, except for some microphone problems. Another nice additions was that we also had a kitchen, where Thorsten and Arjen cooked lots of pasta and sauces.

Calligra track

Most of the time in the general Calligra track was spent on discussing upcoming changes and technologies. With many new upcoming Qt 5 mobile plattforms the mobile Calligra version are getting more and more important. For Calligra as a whole we have to change the way how we integrate the UI with the rest of the applications and which libraries we want to use or not use.

One of the big technologies that that KOffice 1.x was build around is KParts. It was used to embed documents into other documents, to embed the application in Konqueror and much more. Over time many of these usecases have been solved differently or are becoming far less common than they used to be while at the same time it has been making more and more trouble. So our long is to replace KParts in the future. As a one possibility to a new framework Friedrich presented his Kasten framwork. Altogether this will need a lot of time to complete, but will result in a much better architecture.

Beside these big topic there are were many smaller discussion around topics like QML user interface, more focus on testing and an a development process where we created stable snapshots of the master branch. There are also some interesting developments on things annotation and docx export.

A bit sad was the discussion around unmaintained applications. After some maintainers got busy with life recently some application are unmaintained and see no further development at the moment. This is not a very surprising development as we have been working with a bus factor of 1 for years on these applications. Affected by this are Karbon, Plan and Braindump. We decided that for now the applications will get a splashscreen that informs about the unmaintained state, but still stay as part of the official release. Unless new maintainers step up, these application look towards an uncertain future.

Krita BOF

Beside the Calligra discussion we also had a BOF with the Krita developers, which actually took place over all three days. Krita development is running really well and we are more and more popular in areas outside the usual open source community. Boud reported about presenting Krita Sketch at Mobile World Congress and some news from the VFX world. I did already know that Krita was used in visual effects, but so far didn’t know on which movies Krita was used. So it was exciting to hear that Krita was used in production on the upcoming G.I. Joe movie.

On Friday we discussed the main areas which we want to improve in the coming time. The included a better support for Windows and Mac OS, a new OpenGL ES canvas to replace the current OpenGL canvas and lots of smaller improvements. We want to port to Qt 5 as soon as possible as it offers solutions for many these issues. Unfortunately KDE Frameworks is still in the works, so it will take some time.

Beside that I designed the new operation system with Dmitry and Lukáš. The main purposed of that is to separate the UI and operation code in Krita. Instead of connecting everything the old way, we let the application figure out which UI to show and which operation to execute. Instead of signals/slots we use use settings objects to communicate between UI and application. This approach has several advantages: The code becomes more modular, different UIs can be added easily by plugins e.g. for QML interfaces and it can be recorded for macros.

On Sunday I and Boud went through the Krita crashes in Bugzilla and did some cleanup there. Having two different systems and people check at the same time was really productive, as sometimes I could produce other problems on Kubuntu than Boud on OpenSuse and the other way around. For example we found a crash with the Ubuntu jpeg library which didn’t happen on OpenSuse. Altogether we were able to resolve 14 crash reports.

Finally I want to thank KDE e.V and Friedrich for making this sprint possible. Many thanks also go to the cooking team.

More Krita 2.7 features

January 4, 2013

Recently Boudwijn presented his vacation work on the flipbook and smoothing feature. He wasn’t the only one having fun hacking new Krita features. I’m presenting you some of the new features that I developed in the last few days.

Freehand path tool

First feature I worked on was the “Freehand path tool” (Not the best name, I might rename that if I find a better one). Krita users might already know the old Pencil tool that came from Karbon and could also be used in Krita for vector graphics. One of the shortcoming of that tool was that it so far couldn’t use Krita brushes, which confused some users.

To solve that I created a the new tool which internally reuses the pencil tool and uses the painting capability of the path tool. With the result that the new tool can be used on pixel and vector layer. When painting on pixel-based layers Krita will paint with the current brush, on a vector layer it will insert a shape.

One might wonder why this is a big deal compared to the already existing freehand tool. The interesting feature of this tool is that the complete stroke stays a path until it’s finished. This allows some nice post-processing steps e.g. it possible to smooth the stroke much more than the freehand tool can while painting. Small downside with the is that it doesn’t use brush dynamics.

The screenshots below show an example with my mouse path and the resulting smooth stroke painted with a Krita brush (I cranked up the smoothing, so it a far more aggressive smoothing than one would usually use).



Painting any shape with Krita brushes

Almost immediately after I had done the Freehand path tool, I got the next request. If we can stroke any path path shape with Krita, why not add the functionality to do it with all shapes? I thought that would be pretty easy to do, turned out it needed some tricky coordinate transformation. But I finally got it working an the result is quite fun.

In the screenshot below you can see a flower shape that I let it paint with the pixel brush:


Also interesting is that you can open SVG files in Krita and then trace all the paths inside it.

QML Export

The last feature that I added was the ability to export to QML. This feature is especially interesting for everybody designing special QML interfaces. It exports a all the top-level layers in the Krita image as image and creates a QML file where all the images are inserted as image objects, so the QML UI looks exactly like in Krita (if you you the default composite op). Other attributes that are exported are layer name and opacity, which are mapped to the id and opacity of the object.

A very simple example:


Currently it only exports QML 1.1, but that should be easy to change when I use Qt 5.

More coming in 2013…

2013 will be a very interesting year for Krita with 2.6 to be released this month, 2.7 in summer with the features above and then 2.8 in fall/winter. I also think that Krita Sketch will gain more attraction. We have a lots of things coming up in terms of fixes and performance improvements.

Personally the one thing I’m looking most forward to in 2013 is KDE Frameworks 5. I think it will really be a game changer for Krita, allowing us to cut a number of dependencies which will make Krita much more interesting for many non-KDE users. A Krita version based on it will most likely take till 2014.

Don’t forget the Create Konqui with Krita contest. You still have till end of the month to submit your entry.

Workaround for recent Krita crashes on some systems

October 6, 2012

Recently we have been getting lots of crash reports about Krita crashing on certain systems. So I’m putting up some information about the crashes and how to work around them.

Affected by the crashes are some distributions in combination with open source graphics drivers. In openSUSE 12.2 Krita will crash on startup (bug report) and in the upcoming Ubuntu 12.10 (bug report) it crashes on opening the preferences. The problems are some build issues, where the LLVM usage of OpenGTL which used by Krita and the LLVM usage of the graphics driver conflict.

As a workaround Krita users should use the proprietary graphics driver until these issues are fixed. Users of openSUSE can also have a look on the openSUSE bug report, where some new OpenGTL builds are made available over OBS.

Krita compositions docker

May 9, 2012

After Krita 2.4 is released the development for Krita 2.5 is progressing. The first feature that I added for 2.5 is a the new composition docker. It’s based on a request by David Revoy, who also did the storyboards for Mango (they are shooting currently, with a very cool behind the scenes livestream) in Krita.

The idea behind the compositions docker is very simply. It saves the visibility of all layers and can restore them. Composition are also stored to file if you use Krita’s native fileformat.

This is very useful e.g. for  cartoons were characters are in different situations over the same background or movie storyboards. Beside that it can also be used with different combinations of filters e.g. to simulate different color moods.

Last but not least David did a demo video of the new feature:

Krita bug statistics

December 21, 2011

A few days ago  Martin Gräßlin posted some statistics about bugs in KWin. That got me interested in doing some statistics about Krita.

The first thing I wanted to find out was how long bugs need to get fixed. To do that I wrote a script that extracted the data from the Bugzilla csv export, which is quite limited. There is some data available like the creation date of a bug or the date of the last change, but most details are not available directly. So to get the the data to calculate the lifetime of a bug, I approximated the closing date of a bug with the last change.

From the bug data I generated the following picture that shows all Krita bugs from 2004 till now. Each row shows one line whose length represents the time from report creation to it’s closing. Closed bugs are shown as black, new open bugs are green and unconfirmed bugs red. In the background you can see the length of the years and the blue vertical lines show major releases.

Although the diagramm is very simple, there are lots of things that can be discovered. First thing you might notice, is that it looks like there are some blue lines missing in the middle. That not a mistake, but the big gap were we were porting to KDE 4 (Surprised me a bit, as I thought that it was much longer than it looks).

For the bugs themself it shows that many bugs are closed near their creation, but there are also many bugs with evil long lines. After the release of Version 2.0 the curve get much steeper, which shows that more bugs got reported. It might sound strange, but as the software got more stable more bug reports were submitted. I think it just shows that Krita is used much more now and users work more with it and by that find more bugs. It also shows once again that the raw number of bug reports doesn’t mean anything.

Next I plotted how many bugs get opened and closed every year. Both have increased quite a lot of the last few years. As you can see we usually fix slightly less bugs than are reported (slightly above 90%), so the total number of bugs is still growing. No idea if that is better or worse than other projects.

Last thing I wanted to find out was how the bugs are resolved e.g. if they are really fixed in the classical sense or are just duplicates etc. So I extract the resolution from the data and plotted the four resolutions that are by far the most common for Krita. Not surprising of course is that “fixed” and “duplicate” are the most common. Although I was under the impression that we got a lot more duplicates in the last time, the actual number of duplicates isn’t that big (I also did that for Plasma to compare and it really has a crazy amount of duplicates).

One last detail: I know developers are often criticized for closing many bugs as wontfix and it turns out that this at least doesn’t apply for Krita (yet), as only about one percent of all bugs are closed as wontfix.