Monday, June 14, 2010

A brighter future

Well it’s been quite a while since the last post. I’ve been busy with university work, and while I have one more paper to submit in a few days and finals in about ten, I have a bit of free time now.

I’ll be working through the bug reports I received since 0.2.0 final went live. I must say I’m pleasantly surprised that nothing major was reported. I’d like to thank all the people who have written thorough bug reports. I haven’t had time to go through them all and respond appropriately, but I’m getting there.

Sigil 0.2.1 will probably come sometime in late July/early August. While I have a few days free this week, I’ll be studying the following three weeks and immediately after that I’m going on a two-week vacation.

There’s an ever-so-slight chance that I’ll push a very minor bugfix release in about a week and postpone all the work I wanted to do for 0.2.1 into 0.2.2.

I’ve also started work on replacing all the uses of QDom with Xerces-C++ in a separate repo, but that’s going to take quite a bit of time.

What I’ve really spent a lot of time with over the last several days is QtWebKit. There was a bug on the WebKit Bugzilla for the general QtWebKit performance problems… When the bug was reported, my testcase on one machine took 55 seconds to load and render. For Qt 4.7beta1, Nokia got that down to 21 seconds. With the trunk version of Qt 4.7 from a couple of days ago, it’s down to 13.3 seconds. Bottom line, they’ve done some good work speeding it up, and some more work still remains. It’s not native-WebKit or Firefox fast, where the testcase renders instantaneously, but it’s improving.

I downloaded the Qt trunk source a few days ago and extensively profiled QtWebKit rendering. 95% of the time is spent shaping glyphs in the call tree of QFontMetrics::width(), and man does a lot of code get run just to get the width of a text string. The calls drop into Harfbuzz, and all sorts of functions end up eating a bit of wall time here and there, and this all adds up. There’s no single point that does something very stupid that could then be optimized away, at least not in this module. There’s even an internal “simplified” codepath for getting the width of a text string, but I’m not sure why the Nokia guys are not using it in QtWebKit. I’m probably missing a piece of the puzzle. Either way, there was no low-hanging fruit to remove.

The most fruitful optimization work will probably come from higher up the call chain. For instance, there are superfluous layout calls for page rendering, which (if I’m reading the bug comments right) make the whole thing calculate the render tree three times. Ouch. But they’re working on it.

The point to take home is that when Qt 4.7 lands, Sigil should see a very nice performance boost for loading books and switching to the Book View. Probably for general WYSIWYG actions in the Book View too. Hurrah for that.