We’ve already got Valorie here in Deventer, and next week we’ll take the slow train, the international train and then the ICE to Vienna, to attend Akademy. Last time Irina and I attended Akademy was in A Coruña, to present the work I had been doing on Plasma Mobile.
This time, I’m not going to present anything. I’ll be around, I want to listen to people, I want to meet people, I want to forget the past two years, which have been really tough, and I want to…
See this thing in real life. Let’s hope the Kunsthistorisches Museum is open, and hasn’t closed the room with the Cellini salt cellar, or loaned it out…
I like fixing bugs… It makes people happy who have their bugs fixed, it makes Krita better, and it can be done in relatively small time laps. And it gives one a sense of having been usefully productive to go to the weekly bug summary, and see oneself in the top-five of bug resolvers. Not that I’m there right now, though I was last week, because sometimes one has to dig deeper.
These weeks I’m working on refactoring Krita’s resource systems. Resource in graphics app parlance are things like brushes, gradients, patterns — mostly small files that are stored somewhere on disk and that are loaded on start up. This code dates back to 2000 or so and was originally designed for a world where people would have a few dozen of each resource installed, and where brushes and patterns wouldn’t be bigger than 64 x 64 pixels.
These days, people want to have libraries containing hundreds of resources, and many are huge, like 5000×5000 pixel images. Krita cannot simply load all of that in memory like we’re doing now. It takes too much memory. It takes too much start-up time. It makes organizing resources too hard for the user. Because it uses the ancient KDE system for finding resources in the installation, local installation and local user folder in a tiered system, some resources cannot be edited, like with kxmlgui customization files, any application update will spell disaster.
The whole system will have to be scrapped. We’ll have to have a buffer between the actual resources on disk and the application — a caching database. I kinda feel like I’m jumping down an akonadi-type rabbit hole!
And then there’s tagging and organizing and all the bugs that 18 years of accretion have both fixed, added and papered over. The codebase is the most amazing mix of simple-minded, fiendishly over-complicated and sometimes downright mis-guided patterns and anti-patterns.
So, I’m coding, for the first time since the export filter warning project a couple of years ago, lots and lots and lots of new code. It’s fun! It’ll take at least two months of solid work, probably more, especially since most of it is actual research…
Still, going so deep and losing oneself in the high of concentrated coding means that bug fixing falls by the wayside — even though the result should end with scores of bugs closed — that I feel pangs of guilt. I know that this or that thing is broken, and my fingers itch! But I find it impossible to really carry all that’s needed for this refactoring in my head, and dig into problems in other systems.
Some time ago, I compared 2:1 devices, which was a new form factor back then. This time, triggered by an experiment with a Wacom Mobile Studio Pro during the last Krita sprint, I want to look into the various drawing devices I’ve used over the years, and which ones worked well, or not.
This was the first device where I could draw with a pen on the screen. I got it in 2007. The pen technology was Wacom, and it worked with Linux out of the box. The pen was a bit tiny, but could be stored in the laptop itself. The screen only had a 1024×768 resolution, which is incredible these days, but it was fine: nobody was creating 4k images back then. The pen was quite accurate, except at the borders of the screen, a familiar Wacom issue. Palm rejection was fine, and it was a very usable little thing. The hinge mechanism was its weak point though: it turned only one way, and one day someone forced it the other way…
Lenovo Thinkpad Helix
When we were developing Krita Sketch and Krita Gemini, Intel sent us two devices: a Lenovo Helix and a Dell XPS 12. The Dell had a touch screen, but was not pen compatible, the Helix came with a pen, but didn’t have the 2:1 drivers that would switch the device from laptop into tablet mode when ripping it out of the keyboard.
The pen was as tiny as the one in the X61T, and also used Wacom technology. It sort of worked fine, but the device itself always felt cramped when using it for art. Part of that was because the screen was only 11″, part of it because when connect to the keyboard, it didn’t bend back enough, part maybe because it always felt a little slow. It was fairly heavy, too. It ran Linux perfectly well, but not in tablet mode: I never figured out how to make Linux switch automatically between landscape and portrait mode.
The idea was fun, but it was far from an ideal art device, or even a good device for someone developing an art application.
Microsoft Surface Pro 3
It was going at a reduced price, and I wanted something with an n-trig pen, to test Krita with. Plus, I was thinking of, you know, picking up drawing again, and maybe learn how to use Krita. I got the lowest-end model.
When I got it, it was running Windows 8, which was a good fit for the device. Better than Windows 10, to be honest. I liked the PDF reader that came with Windows 8, which got replaced by a web browser by now. I liked to use the device to read comics, too, using the Comix reader. But…
For using it as an art device, there were some big problems: there’s a tiny, but noticeable bit of latency between pen and device. It’s even noticeable when clicking on a menu or a button, and very noticeable when trying to draw. I though that was the n-trig pen, or the bluetooth connection, but later on I learned that this might well be Windows. I never even tried to put Linux on it: this device was for testing Krita on Windows with n-trig/windows Ink, and the 64GB ssd was too small to partition.
The pen is thinnish and not too comfortable to hold, more a Bic feeling than a Waterman feeling. Palm rejection while drawing is pretty bad as well, and there seem to be a ton of things that need to be disabled in Windows before things get to a tolerable state, like all the flicks and things.
In sum, it was slow, laggy and burdened by Windows 10 and all its fancy features that only get in the way.
Wacom Cintiq Hybrid Companion
Wacom contacted us in 2013 and offered to donate some devices to the Krita project so we could improve support for them. One of those devices was the Wacom Cintiq Hybrid Companion.
The Cintiq Hybrid Companion was one of the first attempts by Wacom at creating an untethered art device. It felt (and feels) very luxurious: a very nice sleeve, a nice pen case with lots of replacement nibs and a flimsy but pretty stand came with the device. The pen feels great, too.
The device can run independently, and then it runs Android. The Android version never got updated, though, so it’s still stuck at 4. There were a number of interesting art applications included on the Android side, like Manga Canvas. The application I liked best on Android was ArtFlow. I even considered porting Krita to the device, but never got started. Not a big problem… Wacom never made another Android tablet, and Android tablets with pen support are pretty rare these days.
There were, and are, a couple of issues, though. There is a strong parallax effect near the screen edges. It’s smallish and the resolution isn’t very high. It works best when coupled with a big monitor, two windows and two views on the same image. It’s also rather too heavy to keep on your lap, but as a desk-bound thing it’s fine.
When using it with Windows, touch is unreliable, and when using it with Linux, it is pretty hard to calibrate — and somehow, but that probably is a driver issue, after a couple of strokes it messes up the pointer state, and suddenly every mouse move selects or moves windows, even when nothing is clicked and no modifier key is held.
I keep the companion around, and I often play with it and use it as a test tablet, but until the Linux wacom driver bugs get ironed out, I won’t be using it for real stuff.
iPad Pro 12.9″
Last year, I was thinking of porting Krita to iOS and Android, both because there’s demand for it and because we might be able to generate some extra income to fund development by having Krita in more app stores. I decided to start with iOS because there just are very few Android tablets with a real pen. I got an iPad Pro, created a dev account with Apple and put the dev environment on the krita-for-macOS-build-macbook-pro. I played with some demo scribble application, but by that time I had begun to really, really, really dislike iOS.
I dislike its flat ugliness, its lack of consistency, its invasiveness, the ubiquity of advertisements in the “free” apps. I dislike how indiscoverable features can be. I actually bought Procreate for iOS to check out the competition, and this was the first time in years when I had to read the manual to figure things out.
Hardware-wise, it’s a beautiful, if a bit big, tablet. The screen is great. It’s quite fast. The pen is fine as well, if a bit top-heavy, and doesn’t have an eraser end. Charging the pen is ridiculous:
The available software is weird. I tried OpenCanvas, Medibang, Procreate and Autodesk Sketch. OpenCanvas actually has menus, popup dialogs and everything a desktop application has! Medibang looks quite normal by comparison, but looks and feel more like an Android application than an iOS application. Procreate looks and feels native. It’s all quite usable, and all not quite what I want to use, though.
I’m currently using it to read books on C++ in PDF format (I haven’t found a good CBR or ePub reader for iOS yet…) I still intend to try again to port Krita to iOS, but maybe I’d better sell the thing.
Wacom Mobile Studio Pro
A webshop had a barely-used but seriously reduced price offer for this device. It’s the 16″ model. Pretty much Wacom’s flagship pen tablet, running Windows 10. It comes with a dildo^Wcigar tube^W^Wnew style pen holder, and that’s it. No sleeves, no stands, no usb-c-to-something-useful converter. Even if you want to use it Cintiq-like, you have to buy the Wacom Link converter. For a device at this price level — new it’s more than 3000 euros, that’s a bit mean.
The device itself has its good and its less good points.
Good is the screen: it’s big, bright, high-res and has very good color coverage. Good is the pen: it has a nice weight and with the felt tips feels great when painting. Lots of disk space, choice between Intel and NVidia GPU, also good. Lots of express keys, great.
The Intel Realsense 3D camera never worked, though: it crashes when starting the calibration app. The screen has a yellow splotch in the bottom-left corner (or top-right, depending on how you’re holding it).
It’s heavy, of course, but, well, that’s normal for a 16″ device, and I’ve found various strategies to work with it held on my lap nonetheless. It does get warm, though, especially when we’ve made any little mistake that makes Krita more CPU than needed.
I’ve used it with Windows 10 for about a year: this works, but I noticed it changed my drawing style. More blobby, rendery, less line work. And I’m now guessing that that’s because this device with Windows 10 has sort of the same problem as the Surface Pro 3: a little bit of latency between pen and device.
Which is weird, because it’s Wacom, so the pen and the screen are directly connected, not the pen to the os through bluetooh. So when we had the house full of artists for the sprint, and David, Raghu and Timothee were playing with the device, and they all declared they couldn’t work with it like this, we first tried to find out whether we could improve it under Windows. Disabling the Windows window compositor made a bit of difference, but David was still disgusted with the feel of the device.
Then we tried to run Linux on it. A year ago, that was still a big problem, and when Aryeom of Zemarmot got an MSP, Jehan had quite a bit of work to make things run. However, we just plugged an Ubuntu 18.04 USB stick in the USB hub, rebooted, added a second USB stick with Krita and everything worked.
And the latency was gone! The next weekend, I put Kubuntu on it (still waiting for the 18.04 based release of KDE Neon), and that works much nicer. Pity there isn’t a good HiDPI virtual keyboard for Linux/X11 — but I can just keep my normal keyboard connected to it when I’m drawing and sketching at my desk. There are some problems still: the touch screen doesn’t work in Krita (where the touch screen of the hybrid companion works perfectly), and synchronizing the rotation of the screen and the tablet doesn’t work yet.
Lenovo Yoga 920
I’ve also gotten a Lenovo Yoga 920 at a discount, but I haven’t done much with that yet. Now that the battery life of the Surface Pro 3 is gone, the Dell XPS-12’s keyboard broken and with the Helix out of commission, I wanted something I could take with me (when I go to Akademy, for instance) that I could draw on. But I’ve had very good reports: good Linux compatibility, no latency between pen and computer and it’s very portable. I’ll be spending some more time today getting Krita up and running on it.
So… My blog originally started out as a book review blog, and to celebrate its return (we moved from a home-hosted server to something cloudy), let’s talk about two gosh-darned awful books.
The thing is this: I’ve been so busy with actually maintaining a 600 kloc project that I’ve neglected keeping up with the changes in the language the project uses. Yet C++ has changed a lot, even if our codebase hasn’t. I did buy Stroustrup’s C++11 Programming Language book, but never had time to read it.
And now we’re at C++17. So I thought I’d get a couple of books with C++17 in the title to help me figure out what has changed, why it has changed, how it has changed and what the changes are good for. I got two books from Apress, which is a Springer imprint.
So let’s go for a quick syntax overview. C++17 Quick Syntax Reference. The author, Mikael Olsson, is a Fin, and weirdly enough his bio is smaller than the technical reviewer’s bio, Massimo Nardone. Massimo also gets his picture printed, Mikael doesn’t. Judging from the layout, the book itself is obviously either meant for pre-school children or people with vision problems even worse than mine: the letterpress is enormous. All that would not be a problem, but…
A quick syntax reference has no business explaining how to choose an IDE or how to create a Hello World application. A C++17 syntax reference should also teach modern, 2017-level C++, not 1972 level C. The final chapter, Chapter 27, explains what Headers are, Why Use Headers — with this gem of an observation “C++ requires everything to be declared before it can be used.” Then it goes on the show how to #include a header — heady stuff! After some more kindergarten stuff it finished up explaining include guards.
The book isn’t actually written in broken English, but it is unreadable all the same. Just look at this quote from page 58:
“In addition to passing variables by value, reference, or address, a variable may also be returned in one of these ways. Most commonly, a function returns by value, in which case a copy of the value is returned to the caller.”
Okay, writing this book was a waste of time for the author, unless he’s getting rich from it, which I doubt. It’s a waste of time for the reader, and spending more time on it is going to be a waste of time for both me, and you, my reader. The book will be pulped and recycled.
Next. “Clean C++”: Sustainable Software Development Patterns and Best Practices with C++17″ by Stephan Roth.
Same publisher, same awful print quality, but since Stephan produced a lot of text, the font size is very small. This time the author gets his mugshot printed, and the technical reviewer, Marc Gregoire not. Marc is Belgian, Stephan German and I suspect that the copy editor was Martian. The very first sentence is already broken:
“It is still a sad reality that many software development projects are in bad conditions, and some might even be in a serious crisis.”
Some things are nice, the author uses actual code samples from actual projects, like Apache OpenOffice, to show problems. Some chapters have promising titles, like “The Basics of Clean C++”, but then start exhorting the reader that “Names Should Be Self-Explanatory”. I thought I was reading a book on clean C++, not Java for high school students? Apparently, removing the license header from your source files will also make your code more Clean!
“Advanced Concepts of Modern C++” is more interesting, though either I am dumb, or the author was in need of a good editor to help him explain what he means, because much of the text I just cannot follow. I would also have liked some clear explanation of why automatic type deduction is good, while at the same time, we’re exhorted to do Type-Rich Programming. The rest of the book rehashes in an an abbreviated way what was explained much better elsewhere: Object Orientation, Functional Programming, Test Driven Development, Design Patterns and UML.
The book promised to show how to use C++17 to write clean code. Instead it regurgitates every bromide from Code Complete and similar books published in the past two decades without adding anything interesting or even talking about C++17 much.
Maybe I’m hypercritical these days… But this book will also be pulped. In any case, any suggestions for something that will teach me to read and write real modern C++17 are very welcome!