Creating a state-of-the-art digital painting application is neither easy nor cheap. After last year's success, Krita is launching their second Kickstarter campaign, this time — to fund painting performance improvements and complete the work on animation support.

We asked Boudewijn Rempt, the project leader, a few rather technical questions about the planned work.

The first of your grand plans for this campaign is taking on Photoshop in terms of painting speed. What exactly are you going to do?

We knew all along that Photoshop works interactively at reduced sizes — basically on a mipmap of the original image content, not just the display, and probably also compresses the image data it isn't using directly.

So last year, during last year's kickstarter, Dmitry started looking into how that would function — you have to juggle virtual memory, the mipmap, the compression... And we got far enough for a proof of concept.

It needs to be done right inside Krita's core tile engine, which is coincidentally also where we need to make changes to support frames in paint devices (for animation).

With a "let's make it faster than Photoshop!" slogan wouldn't you end up in a situation where people would request running sensible comparative tests between two apps when you're done?

That's not unlikely. The main focus is painting: what we did last year was draw a diagonal across the canvas and visually check lag. If you set the cache levels in Photoshop CS2 to 1, then it behaves much like Krita.

Isn't there a way to measure that lag programatically?

I haven't looked into that. We do have some benchmarks that measure painting speed, though

Do you expect using these benchmarks much or rely on perceptual tests?

It's up to Dmitry, but for comparison, mostly perceptual tests, I think. After all, we can't instrument Photoshop. The most important things is that painters should feel it's just as fast and smooth so they can switch to free software, to Krita, without giving up productivity.

On the campaign's page you mention upcoming support for "big brushes with a diameter over 3000 pixels". Is it about meeting the rising market's demand for content that looks good on 4K and beyond?

Yes, we see that people are making bigger and bigger images, using bigger and bigger brushes. I'm not totally sure why. Sometimes people work with resolutions that seem unnecessary high, especially for web comics. But on the other hand, if they want to go to print, it might be necessary.

You have a student who's already working on animation within Google Summer of Code 2015 program, and now you propose another paid project for that feature. How will those converge?

Basically, doing animation right needs more than one student: we expect we'll need at least 3 months full-time work from either me or Dmitry as well.

So at least two people overall?

Yes, it's a big job, and Jouni Pentikäinen is doing really well, but it's too much for just one guy. We really want to avoid another proof-of-concept that's almost ready to be merged, but not quite.

This is what time you start adding animation to Krita now?

This is our fourth attempt at animation, and we want to do it right, with all that we've learned before.

Regarding implementation details: is some sort of basic tweening planned, as much as is possible for bitmaps?

What we want to do is put (nearly) all properties of layers and masks on a timeline with a curve. Which means that a transform mask will transform in between keyframes, and that will transform the associated raster data. Same with filter masks and layers.

So there will be keyframes?

Yes. In fact, they already are there, we've got a working prototype, tough using it is an exercise in working around bugs, of course.

But you don't have the image processing core exposing properties to the animation engine yet?

No, that's part of the plan. Right now, only swapping pixel data is 'done'. We always used to have animation as a plugin, away from Krita's core, right now it's going to be deep in the tile manager.

What do you expect will be the most difficult part?

Memory consumption, which is why we've got the performance target as well — Dmitry and Jouni have spent a big part of the sprint weekend two weeks ago doing a really careful internal design.

Do you mean consumption bump would happen because of calculating and executing all transitions?

Not just that, consumption all in all. People will want to do a 30 second clip with 10 layers at 1920x1200 or even higher. That's never going to fit in memory if we're naive about it.

Will you have to rewrite the tile manager much?

Parts of it, part of the rendering engine. Dmitry wants to build on his level-of-details proof-of-concept he did last year.

Will there be some smart caching/baking involved?

Both, I suspect. Caching of layer data, baking of rendered frames.

Meanwhile Blender is going further with their own painting feature set, if you saw the recent video...

Yes, the world is big enough for Blender and Krita :-)

When we're done, potentially every Krita's .kra file will have animation, so one thing I'm looking forward to is people like David Revoy using that to make Pepper and Carrot even cooler.

You can support Krita on Kickstarter. If you aren't familiar with the software yet, grab your download at krita.org, it's free forever.