Tuesday, April 20, 2010

So by now, you should know that QtWebKit is slow. Damn slow. If you don’t, refresh your memory.

If you're performing an editing operation in Sigil, and the UI blocks for 10+ seconds, it’s QtWebKit. If you’re loading a large HTML file into the Book View and everything grinds to a halt for 30+ seconds, yeah, that’s still QtWebKit. I’m not saying all the code I write is perfect (far from it), but QtWebKit has a special place in my heart of hatred.

Back in that loading performance post I linked, I talked about how it takes 75 seconds to load Three Men in a Boat in Sigil 0.1.9. Some of the Linux users may have been confused by that, since on comparable hardware, it would load much faster on a Linux machine.

And it’s true. Sigil performs about an order of magnitude faster on Linux than on Windows. Why is that?

Well it’s because while Qt is thoroughly tested on Windows, it’s certainly much less tested than on Linux. Qt developers are Linux users, and a lot of them are KDE developers as well. So the machines they use don’t run Windows. It’s a lot like the Sigil UI being fine-tuned for Windows, since I use it and develop on it almost exclusively.

So when there’s a performance regression in Qt on Windows, there’s a fair chance someone at Nokia will miss it. And they did.

The test case I attached to the bug report loads in 55 seconds on Windows and 6 seconds on Linux. Bear in mind the same test case renders instantaneously in Firefox, and probably also in Safari (although I haven’t tested it) which uses vanilla WebKit. Horrible, I know. They’re finally coming around to fixing that, since the bug is now included as one of the “release critical” bugs for QtWebKit 2.0 (which is now officially a separately released project from Qt). That means they’ll kill it before the next release, which should be sometime in May (Qt 4.7 a couple of months after that).

Here’s to pigs flying.

…and another thing

Remember the font variants issue preventing official font embedding support in Sigil? The QtWebKit bug causing the underlying problem has been tracked for the last eightfifteen months on their various trackers, and I’ve been told just a few days ago that it’s “not considered critical to the release” of QtWebKit 2.0… which probably means it won’t be fixed for at least another six months.