Krita Windows and Mac OS progress

July 25, 2011

Good news for all users that don’t use Linux but still want to run Krita. In the last week lots of progress has been made towards getting Krita to run on Windows and Mac OS X. The Windows work was work was done by stuartmd who is working for KO GmbH. The screenshot below shows current git master running on Windows. The native windows look is a bit ugly, but can of course be changed to Oxygen.

A Windows installer for Krita is expected for the next version later this year. I expect that we will have a quite long testing phase, as there are not many Windows developers and Windows users aren’t used to file bug reports.

Quite a suprise was that almost at the same time forum user pkouame managed to run Krita on the newest Mac OS version. Krita did run on Mac OS for some time, but after almost no Krita developer has an Apple computer anymore so practically nobody did run it.

In other news Anitims Krita DVD can now be preordered.

Krita Sprint 2011: Technology and art

June 4, 2011

Last but not least my report from this years Krita sprint. It was the third sprint just for Krita and it was even more amazing than last years sprint. After being at Boud’s house last year we went to the Blender Institute. The move was necessary as the team did grow quite a bit in that time. The second big change from last year was that this year also some artists attended the sprint. As far as I know it’s quite unique that developers and users meet at a sprint. Although they are not just users, but an important part of the development team and have a huge influence on the direction in which Krita is developing.

Artist demos

So why did we invite artists? Many (if not most) Krita developers, are not (professional) artists, so we depend on artists to show us the bugs and workflow problems that they encounter. It was planned that each of the artists would show us about 30 minutes of painting and we would analyse what we could improve.

The demos were really interesting and surprised me at many points. One thing that especially surprised me how good Krita performed during the demos. I usually see Krita from the other side where I known all the existing problems, but the demos did only show a few even when using the most recent development version. The next thing that really surprised me is that some features are more used than I ever imagined, e.g. presets are used a lot and I had not thought that when I added them.

Another interesting observation for me was that all the artists had totally different workflows. The way the build up their images as well as they used Krita was really interesting to see. For example Animtim works with a gamepad in one hand and the tablet in the other hand. Interesting was also that most artists used suprisingly few features and had had configured lots of shortcuts. The screencaps with are available here (with our discussion as audio).

Planning the next year

After the demos we discussed the plans for the next year. There are lots of things that will be coming with the next version, but most of the work goes into polishing with only some bigger changes coming. The only planned refactoring will be in the selection system, this includes also grayscale masks.

For many users interesting is a news that Boud had: There will soon someone who is paid working on the Windows version of Calligra, which will also includes single-application installers. The Windows version always was something we wanted to have, but since all developers are working on Linux nobody was interested in working on that (Mac situation is even worse as most developers don’t even have Apple hardware). I’m hopeful that it can be ready for the next version.

Hacking

After the official part closed we went to implement the things that where noted in the demos in the morning. First I changed the preset dockers as Bugsbane suggested that we should keep the aspect ration of presets and also use the space more efficently. So now the preset docker will keep the presets square while maximizing the usage of the available space.

Another change that I did was to move the opacity setting from the tool options to the toolbar. Now the opacity works globally for all the tools and Silvio is working on the paintop integration.

Finally I also modified a few shortcuts. The brush increase and decrease shortcuts, so now the adapt to the brush size and make bigger changes when the brush is bigger. That one was also quite funny as we had the direct feedback from the artists. We developers had a discussion if the functionally needed to be even better (like exactly following a exponential curve) when the artists said that it was already perfect for them.

This are only the changes I did. There are some many things going on in Krita development at the moment with about half a dozen different branch working on various features.

Many thanks go to Ton Roosendaal and the Blender Institute for the amazing location and of course KDE e.V. for making the sprint possible.

Krita 2.4 progress

February 8, 2011

Since we released Krita 2.3 last month, the development of Krita 2.4 has been running at an incredible pace. So I thought it might be a good idea to show what we have been doing in the new version.

Since we released we got a huge amount feature wishes, so I took some time to implemented some of them. Most of these changes we in the user interface, as can be seen in the following screenshot.

If you have used Krita 2.3 and earlier versions you probably notice that the tool- and statusbar now take a lot less space. The funny thing behind this I never really noticed it before (I guess as KDE user I was very used to bigger margins and due to my big screen it never bothered me much), but then I saw some Krita on Gnome screenshots (like here) and there is was very obvious.

One very surprising thing about the Krita is that many users are actually running Gnome. There are no exact numbers, but my impression is that there are at least as many Gnome users as there are KDE Plasma workspace users running Krita. After all the discussion in the recent time I think that the users are already much further than the distributions. KDE applications can work and look good under Gnome, but it still requires too much manual fine-tuning to get the best result.

I did a bit more cleanup in the toolbox, where I removed some of the tools that are no longer needed. For example the instead of having on path tool for vector graphics and for raster graphics, we now have just one tool that can switch between the the two based on the context.

In the toolbar the there are now two new functions. The first is that we now have the control for the horizontal and vertical mirror modes in the toolbar, so they work globally across different tools. The modes were added by Lukáš for 2.4 and allow to mirror the current brush painting around one or two axis. It turned out that this feature is quite popular and already produced some very cool results. The only missing part are some good icons for it.

The other new feature in the toolbar is the workspace chooser, which allows to create and switch between workspace. Since Krita has lots of different dockers, which can either be docked or floating, it can be hard to manage them. An artist might want to use different docker arrangements for painting, layer management or vector graphics, so the workspace chooser allows to save a docker configuration.

In the future it might also be possible to save other properties of the environment like the active tool, brush engine, pattern or gradient. It’s not completely clear which properties would be useful, so for now I only saved the docker state. We also thought about a possibility to save it to the current file so that it would be possible to always have the same workspace when working on a certain image, like it’s already done in Blender.

Finally we improved the dockers a bit. I have added a new channel docker that allows to switch on and of channels. Currently it still very simple and doesn’t have the full funtionality that other applications provide yet. Below the channel docker you can see the new preset docker that was added by Adam for 2.4 and provides the same functionality that 2.3 has in the preset popup now also in a docker. By the way: The presets in the docker are from the first user-made preset collection.

Vector graphic file import for Krita

December 12, 2010

For quite some time Krita supports shape layers now. It’s quite surprising that many users are use the vector features even though they are not as powerful as in pure vector graphics programs. Probably one of the biggest problem in the 2.3 and before was inserting vector graphics.

While inserting primitive shapes is very easy, inserting complex vector graphics was rather difficult. There were two ways to insert them, you could either open a file with the file dialog and it would get rasterized or you could copy and paste it from Karbon. After Kubuntiac brought up the wish to have better SVG support, I took over and added the new import filter.

The actual filter turned out to be really small as it just needs to open the file and find out which shape should go to which layer as the rest is done by flake. The filter at can load ODG files. After some fixes from Cyrille the filter can now also load SVG files (we use the Karbon SVG import). Pretty cool is also that we preserve Karbon layers as well as layers form Inkscape SVGs.

Parallel brush mask processing

October 25, 2010

This weekend I was a bit tired of fixing Krita bugs and decided to do work a bit on features again. So I started to work on optimizing the painting in Krita again (though one could see performance issues as bugs).

Lukas had already optimized brush masks before mainly by improving the algorithm. Back then the goal was to be able to have fast painting with a 70px brush on a 2500×2500 image, the new goal is a 500px brush on 6000×6000 image. When I looked at the CPU utilisation of the stroke benchmark I noticed that only on thread was busy, so I wanted to try to parallelize it. I know that KSysguard might not the most precise way to measure it, but it gives a nice indication:

The first thing I wanted to try was OpenMP which I knew through my Algorithm Engineering course from university. I tried to use for-loop parallelization, but it did work out very well as it turn out even slower than without. I’m not completely sure why that happened, but I assume that the loop wasn’t well suited for OpenMP.

After that my next try was to use QtConcurrent on the problem. My idea was to split the mask into a list of separate rectangles where the threads could work. QtConcurrent was suprisingly easy to use and I only needed to make very few changes to the old code. Here is the result of the benchmark with QtConcurrent code:

The random lines with 300px brush benchmark improved from 9359 msec to 5621 msec which is a speedup 1.6 on my Core i5 430 (dual-core). That isn’t too bad if you consider there is also some serial code in there. For smaller brushes the speedup is much smaller. Unfortunately I don’t have a quad-core system to test, it would be interesting to see how it scales. I’m still wondering why the QtConcurrent code doesn’t run with 100% CPU utilisation. The benchmark should be big enough to reach the maximum.

Since Krita is currently the feature freeze currently, the code won’t make into Krita 2.3.

Sintel released

September 30, 2010

The Durian team has released the newest Blender open movie Sintel.

We visited the Durian team during the Krita sprint in february when the movie was still in an early stage. At that point the movie wasn’t more than a few minutes of animatics and storyboards. It’s nice to see how they turned out in the final version. Especially interesting was the scene from 4:50 till 5:30 which was discussed back then, which turned out really great with the lightning and soundtrack (and is also my favorite scene).

It’s much bigger than the previous movies and really show the progress that has been made since the first one. It’s a huge success for free open source graphics software. I’m already looking forward to the next Blender movie. I hope future Blender movies will use Krita (I will be working towards this).

Amazing job. Thanks so much Durian team!

ODP support for Okular

July 20, 2010

As you probably read on the Dot yesterday Okular doesn’t support much of ODF. I remembered that Jos had created the Slidecompare tool, so I got the idea to combine it with an Okular generator. It turned out that it’s pretty easy to combine the ends from both worlds. Okular offers a very nice API to write generators, which is almost an exact match to the KOffice one.


The generator currently supports only formats supported by KPresenter: ODP, PPT and PPTX. Currently only rendering is supported (so no search).

The generator is now in KOffice trunk. Even though it’s just 107 lines of code, it can make use of all the work that went into the KOffice import filters. I love integration!

KOffice font rendering again

July 9, 2010

A few months ago I blogged about font rendering in KOffice. The problem has been discussed and analysed a lot on the last KOffice meeting and the KOffice forum. The conclusion was that the problem can’t be fixed inside KOffice, but needs to be fixed in Qt. Since the problem is far from trivial and we don’t have developers with experience in that specific area, we rely on Nokia to fix the problem. Problem has been reported in two bugs here and here. Unfortunately the bugs have very low priority at the moment, so we need to make clear to Nokia how much these fixes are needed.

Everybody who is bothered about these rendering problems please vote on the two bugs I pointed out above.

In case these bugs don’t get fixedm a possible plan B would be to switch the rendering to use Cairo + Pango. Till then you can try to work around the problem as I have pointed out in my old blog post.

Have you seen this widget?

July 1, 2010

For some time we have been searching for this widget for Krita. It’s basically a button group with adjacent buttons (see the mockup that Jaroslaw made).

It’s a very common UI element e.g. in Plasma or Blender, but it seems that  no KDE application uses it. So has anyone seen this widget used in KDE (outside Plasma) or implemented it?

I’m asking because if doesn’t exist yet (which is very unlikely in my opinion) we would have to implement it ourself and I would prefer not to duplicate existing work.

We need more bug reports

June 25, 2010

The Krita 2.3 is now in development for some time and we try to make it as fast and stable as possible. For that we need more tester.

Krita has often been criticized for being too unstable, like c’t (german computer magazine) who wrote about Krita being “absturzfreudig” (likes to crash). So it shouldn’t be any problem to get lots of bug reports. Right? In practice we don’t really get a lot of bug reports. Which leads to a recurring pattern: Every time we prepare a new release, we fix almost all reported crashes in Bugzilla (Crashes and data loss are considered release blockers) and still miss crashes that haven’t been found. So Krita definitely doesn’t get as much testing as would be needed.

As I mentioned most of the testing is done by Krita developers and a few enthusiastic artists. Even though this group finds most of the bugs and fixes them, we can’t do the testing alone. There are several reasons why we need lots of other testers. Krita is a quite complex application and even though we have less features than comparable applications nobody can test all of them. Additionally Krita runs on a large range of platforms, libraries and hardware. The developers run only a very small subset of these.

Another problem with developers testing an application is that they know a lot about how the application is “supposed to work”. So the way the developers use the application is different than somebody who is new to Krita and don’t seem some of the problem that new users have (I’m wondering if that effect has a name). So we need tester who have less experience with Krita.

One might argue that we should to test it longer and do more beta releases. The problem with that is that not many people test beta releases. Most bugs are reported several weeks or months after the final release. Of course the fact that we currently don’t have that many users plays into it. There is a bit of a contradiction: To get many testing users we need advertise Krita more, but before we can advertise it we need more testing.

To summarize we need more testers, testers that are not developers and have them test Krita earlier.

One thing I notice regularly is that many users have problems, but don’t report them. There might be be several reasons for that like Bugzilla being to slow and requiring to register or they assume that the developers already know about the problem. We are trying to improve on that e.g. with the Krita forum where several users gave us feedback about their usage of Krita, which is very much appreciated and already gave valuable input. In 2.3 for example we redesigned the the eraser after some user reported problems with it.

I hope I have motivated you to test Krita, give feedback and help us to improve it.


Follow

Get every new post delivered to your Inbox.