Fading Memories

For months, everything seemed fine in tablet-on-linux-with-Qt land. Or relatively fine. I could sketch with impunity using Krita 1.x and Krita trunk (unless I tried to paint outside the image itself, that is). A first gentle reminder of the state of tablet support under Linux/X11 came when Naomi wanted to try the Gimp for a change and she noticed that there was an offset of about a hundred pixels between her pointer on screen and where the drawing went. I shrugged and told her she'd better use Krita then.

Then Krita started crashing whenever I tried to use the stylus on my tablet notebook. Lukas Tvrdy suddenly lost tablet support. Cyrille Berger went on to investigate and discovered that we were getting spurious mouse events between the tablet events. Now KOffice is pretty smart in that it tries to map every input device, every individual wacom stylus, art pen or whatever the user has to its own tool. Spurious events that belong to another input device mean that tools started switching in mid-drawing, which in turn deletes the brush engine we were drawing with before we are done drawing. Ouch. A workaround is possible, of course, but workarounds have a nasty habit of coming back to bite the developer in the fleshy parts.

But plain painting with a tablet at least used to work without crashing -- and I have no idea what has changed. And, unfortunately, there is a host of issues with Qt's tablet support anyway: ranging from being hard-coded to certain names in X11.org (stylus and eraser, cursor isn't supported at all), which means Qt effectively doesn't have tablet support on OpenSUSE, to event compression (which means that we don't get all tablet events, which in turn means ugly lines because we cannot track exactly the artist's hand movement.

For reference, these are the Qt issues we're dealing with:

• 193856 - Allow disabling of compression for mouse/tablet events
• 160626 - Tablet events are incorrect when leaving the QWidget
• 187372 - Qt does not recognize all input devices on X11
• 210132 - Qt expects hardcoded wacom device identifiers from xorg.conf
• 207389 - When the tablet device changes after the application has been started, QTabletEvent::device() still refers to the old one
• 193475 - Mac; Graphire 2 tablet stylus device not detected properly

None of them seem close to being closed. The last one is for OS X -- I'm not sure how good the support for tablets on Windows is since I cannot test Krita on Windows with my tablet due to Microsoft messing up their upgrades. (In order to have a Windows in a virtual machine, I first need a Windows installer, and those are not free.)

So... What now? We have basically two choices: try to improve Qt's tablet support and submit a patch to Trolltech (or try to get paid for improving it?), or re-instate our old Krita 1.x tablet code. It had the same problems with detecting devices that aren't called "stylus" and "eraser", but at least we handled the "cursor" device and we managed to handle the event compression very well. Detecting when a user had changed between tablet and mouse was quite buggy, though, in 1.6. And if we resurrect our old code, we can do so for just Krita, or for all of KOffice. Or we could disable the code that maps an input device to a tool instance, but that would suck big time for artists who have gotten used to pan with the mouse and paint with the pen (like me).

Lukas Tvrdy, the Krita Google Summer of Code student currently has one of the two wacom Intuos tablets with art pens the community has sponsored us with. (The other is with Emanuale Tamponi). One of the goals of us having these fancy tablets is making sure Krita does interesting things with features like tilt and rotation, and one of the goals of Lukas' summer of code project is to make a chinese brush brush engine that takes these parameters into account. But, of course, serendipity is always welcome:

I've asked Lukas to make sure that we won't lose this effect through over-eager debugging :-)

Krita already had filter plugins: filters take pixels as input and produce possibly different pixels as output. Filters in Krita can be used destructively: to change a layer or a mask directly. They can also be used dynamically: either in adjustment layers that filter the result of the layers under the adjustment layer in the layer stack, or as filter masks, that filter the contents of a single layer. Or you can paint with them, and in the future you can associated filter parameters with the pressure, rotation and other types of input from your input device. I'm working on that...

But now, requested by Matthew Woehlke, there's another type of plugin: generators. Generators take parameters but not pixels as input, and create pixels as output. That's ideal for things like Apophysis-like plugins. Right now you can only use these generators in Krita on paint devices, as fill types (similar to solid colors or patterns) with the fill tool or as dynamic layers. Painting should be possible, too, but that needs some work. And it would be nice to use this kind of noise in a transparency mask or in a filter mask: that's already possible, but not in a dynamic way.

There's just one snag: I'm not a mathematician, so I depend on other people to write nice generator plugins! Matthew has promised to do something Apophysis-like, but we need lots more: flames, clouds, checkers, waves, marbling -- for someone with the right kind of knowledge or no compunction about copying code from other free software, the possibilities are endless!

So today the Wacom Art Pen arrived -- thanks are due to Cornelius Schumacher, Thorsten Zachmann and Eva Brucherseifer and Axel Jäger who busied themselves with paying, ordering, checking, sending on after a misdelivery! The art pen has a very nice feel on the tablet, a kind of resistance that makes drawing a lot of fun. And there appears to be not a single X11 application that makes use of its rotation feature.

To celebrate the new tablet I have started working again on my Chinese brush simulation. I'm working on the research done by Clara Chan. The Krita version works -- somewhat. The lines the brush bristles draw are not anti-aliased. There is some support for tilt, but not for rotation yet -- which would be quite interesting since rotation of the brush is one the ways to get the right effects when painting in the xiao pin style.

Apart from the cool things we can now develop for the tilt and rotation features there is another thing: the koffice input device architecture goes way beyond what other applications do. In an application like Photoshop or Corel Painter there is only one active tool, no matter which input device you pick up. If you paint freehand with your art pen, and then grab the mouse, click the pan tool, then pick up your art pen again, your art pen pans.

Already with Krita 1.6, you can select the pan tool with your mouse and a paint tool with your stylus. To me, this feels like a very natural style of working. If I paint with real oils, I tend to hold the active brush in my left hand, and in my right hand the palette and a quiver of other brushes of different sizes and with dabs of different colors. If I work with pencil or charcoal, I have a stick of charcoal in one hand and an old cloth in my other hand to soften the lines.

With KOffice 2.0, every input device, even every pen you've got for your wacom has its own tool. So, if you've got an airbrush, a stylus and a mouse, your airbrush can be associated with the freehand tool and the airbrush paintop, your stylus with the freehand tool and the chinese brush paintop and your mouse with the pan tool. And if you've got three styluses, each one can be associated with a certain tool or paintop. Without needing to configure stuff, of course, you can just select tool and paintop by clicking on them. We have already implemented this, but testing with different wacom input devices was a bit hard.

What doesn't work because of an unfortunate but fixable design oversight is having different active colors for different input devices: that would be the ultimate (although expensive) analogy to working with real brushes! (We'll also have to persist the state between sessions, too)

Gone are the dialog-bound preview widgets of yesteryear! Yesterday I managed to have a live filter preview in Krita for the first time:

As you can see, it's not perfect. There are some artefacts that suggest that I have an off-by-something error somewhere...

The idea is to have user-definable, draggable area that's filtered by the filter and settings currently selected in the non-modal dialog box you see top-right, automatically updated some time after you made your last change to the settings. Then, when you're satisfied you can selected to either create a live filter mask (which can have any shape, of course), or destructively filter the current layer, which takes into account the selection (of course).

The draggable and resizable part will probably only be done for 2.1; right now I'm already quite deliriously happy that we've gotten this far.

It's been a long slog getting this far: I had hoped to be done in May, but real life (like buying and renovating an old house and getting a new job) interfered. Not to mention bugs, design errors resulting in two redesigns and the occasional priority shift because we needed to refactor selections, redisplay code, the filter api and other stuff just to get here.

But what we've achieved now is pretty cool, even with all the bugs:

We've got a layer stack that can contain paint layers (with a fixed, i.e., dried, and a changeable, i.e, wet, part), group layers, adjustment layers (that act as a filter foil on top of a stack of layers), copy layers (that copy the result of another layer to a new place in the layer tree) or Flake object layers.

All these layers can contain a stack of masks: selections (containing both vector shapes and per-pixel selectedness) that you can paint on and that can control transparency, apply transformations (like rotation or moving), apply any filter or simply indentify selectedness of pixels for a particular layer.

For as long as I can remember, articles on scaling images have been accompanied by proofs of prowess by scaled versions of one particular image of a particular lady, apparently called "Lena", either in black & white or in color. A quick google will bring you hundreds of projects that have one or another version in their repositories. Who started using this image? Where did it come from?

At least it's a fairly tasteful image, not like some of the images the first KImageShop developers used to showcase KImageShop. But to keep in with the wider tradition, I've started to use lena to unittest our prescaled canvas projection code. Which code is giving me considerable trouble...

My new job means using Windows, and that means a laptop with Windows on it. And since I didn't have a linux development machine anymore until yesterday, I tried to compile KOffice on Windows. I managed to compile it all right; running didn't work.

But that's no problem, because Jaroslaw Staniek had me beaten to getting KWord running (albeit without most plugins) and Adrian Page has made Krita run under Windows. In his own words:

Krita's been running on windows for a couple of weeks now, but I never got round to reporting the progress.

So now Krita is truly cross-platform: it runs on X11, OS X and Windows. I hope to get my Linux development system up and running today so I can start fixing the layer/node structure tomorrow & the qpainter redisplay code. To to start making progress again!