Like for the other parts of Qt, having great performance is important for QtWebKit.
Traditionally, QtWebKit has been mostly used on desktop computers for advanced layouting, hybrid applications or simply to browse the web. On a modern computer, the speed of WebKit is not a problem.
The world has changed, and QtWebKit is now used on mobile phones running Maemo, Symbian or Windows CE, and it is more and more used in embedded application on various devices.
To improve the performance of WebKit, we works with benchmarks. Those benchmarks are used as use cases when profiling WebKit and to evaluate the gain of our patches.
Those benchmarks and the tools are available on Gitorious, in the QtWebkit performance repository.
WebKit gives a lot of possibilities, and we try to focus our work on what matters. For the performance work, we use real webpages, and look for ways to improve WebKit in the way it is used on the Web.
The performance suite has three kinds of tools:
Let’s have a look at the tools and the tests. The full documentation of the performance suite is on the WebKit’s wiki.
For the benchmark, we do not want to access Internet directly. We want to compare the results from one run to the other, so we don’t want the pages to change arbitrarily. Using the Web for benchmarking would also create an important load on the servers.
To use real pages without going online, we create databases of web pages with the mirror application:

Those databases are snapshots of webpages at a given point in time, and they are used as input of the benchmarks.
The mirror application uses WebKit to load the pages and intercept all network requests. This means the database also includes resources that are loaded lazily via Javascript.
There are two ways to exploit the databases with the benchmark: the online and offline modes. The difference lies in the way we provide the database’s content to the benchmarks:

In the “online mode“, we use a basic web server to serve the database over HTTP. The benchmarks use the complete stack to load pages, as they would if we were loading the page from Internet.
In the “offline mode“, the database is loaded directly by the benchmarks and is used as the source of data. In that case, the network is not involved. This mode is mostly useful for the benchmarks that do not involve the network (like measuring the rendering speed).
What is measured
The benchmark suite is still a work in progress. Currently, there are benchmarks for:
If you use WebKit, and are interested in great performance, you can use the performance suite to profile the use case you are interested in, and optimize those cases.
If you evaluate the use of WebKit for embedded, you can use the benchmark to evaluate how good WebKit performs on the hardware.
If you make patches for WebKit’s performance, have a look on how to contribute. You can also join us on IRC in #qtwebkit on freenode.
Nate got his start in WebKit with helping to upstream Javascript bindings for the Chromium port into WebKit. During that work, he learned much about WebKit style as well as getting to know the bindings quite well. Since then, he continued to do a prodigious amount with the bindings and improved them in many ways. In addition, he also added noreferrer support and fixed bugs in a variety of areas such as the loader and plugin scripting.
Please join me in congratulating Nate on his reviewer status!
Hi!
Here’s the weekly summary of Qt related changes to WebKit trunk. Big changes include Yael’s patch for WebSockets support, the beginnings of QtScript on top of JavaScriptCore’s C API, Maemo 5 tweaks and layout test fixes:
http/tests/history layout tests! (34167)websocket/tests in the layout tests (34180).QAbstractKineticScroller (34267).display() method in the Qt DRT (34258).WebCore::String and QString by avoiding QString::fromUtf16() (r54060).By noreply@blogger.com (Ian Fette) at January 28, 2010 09:59 PM
By noreply@blogger.com (Ian Fette) at January 26, 2010 10:03 PM
Jeremy has done a lot of work on local storage and session storage within WebKit. Much of this brought it up to date with spec changes, but he also improved it by adding quota support and fixing many bugs. As part of the Chromium port, he also worked on its WebKit api and JavaScript bindings.
Please join me in congratulating Jeremy on his reviewer status!
This week has been a very busy week! Here’s a list of the landed changes that affect the Qt port, in chronological order:
QGraphicsItems with enabled CacheMode and the animation is driven by the Qt Animation Framework.The feature is disabled by default currently as it’s not stable yet, but it’s a fantastic start! (33514).window.close() and window.closed() in the Qt DRT (32953).Object.getOwnPropertyDescriptor (33948, 33946).From the W3C spec: The name “ruby” originated from the name of the 5.5 point font size in British printing, which is about half the 10 point font size commonly used for normal text.
A ruby annotation is a short piece of text in smaller font, written directly above or below or – with vertical text – to either side of the base text. It is most often used in East Asian typography in order to provide further information. Most commonly it shows the pronounciation of Chinese characters. Another use case is in text books, to give the foreign spelling of a native word, or vice versa. In literary text or Manga ruby is also sometimes used to specify a variant pronunciation of the underlying characters, to add some depth or twist to the normal understanding. However, there is no reason to limit ruby to East Asian text. It can also be applied to other languages for much the same purpose: to specify annotations or give further context.
In this regard note that ruby is a typographic tag rather than a semantic tag like the <abbr> or <dfn> tags that may seem to fill a similar role – by using <ruby> one specifies how the text is to be displayed rather than what its relation is to the base text.
The WebKit ruby implementation follows the HTML5 spec for the tags used. The tags themselves are rather simple:
<ruby> some base text <rp> ( </rp><rt> annotation </rt><rp> ) </rp></ruby>
where:
| <ruby> | Encloses the whole annotated part of the text. |
| <rt> | Encloses the ruby text that is to appear in smaller font above the base text. |
| <rp> | Contains optional parentheses that appear if the user agent does not, in fact, render <ruby>. |
Regarding the <rp> tags: browsers that don’t “understand” ruby will just output the whole content as is, disregarding the unknown tags. This includes the opening and closing parentheses provided within the <rp> tags, as shown in the following image:
Browsers with ruby support, on the other hand, will ignore the contents of the <rp> tags and place what is contained within the <rt> tags in small print over the base text:
To give a different example, here is a sample text in Japanese annotated with English translations of the main words in Kanji characters:
The current implementation follows the outline described above and should satisfy all the basic usage for ruby. This does not mean that implementation can be considered complete – there are two main areas that deserve future attention: character spacing and positioning.
Character spacing: Traditionally, in East Asian typography the characters that make up the ruby text annotation or (less commonly) the base text are spaced such that they line up cleanly.
Positioning: It is sometimes desirable to have the ruby text be positioned below (i.e., ‘after’ in HTML5 parlance) rather than above (’before’), or even in both places. One use case for the latter is in textbooks, e.g. to give a Japanese student both the Furigana reading of a particular Kanji word (usually displayed above the word) as well as the translation (usually below).
Both are addressed by the CSS3 spec, which is based off the XHTML ruby module. However, there are some small but significant differences between the HTML5 and CSS3 ruby specs. Most notably, HTML5 allows several spans of base text and annotations within a single <ruby> element. This is useful to annotate several chinese characters in a row, e.g. (example taken from the HTML5 spec):
<ruby> 漢<rt> ㄏㄢˋ</rt> 字 <rt> ㄗˋ </rt> </ruby>
The CSS3 ruby module on the other hand specifies a version of ruby called complex ruby, which separates ruby base text from annotations in a way similar to <table>. In the future we hope to bring these two conventions together cleanly.
For reference, CSS3 contains a few modules that more or less directly pertain to ruby rendering. Note that, as indicated above, the current implementation does not (yet) address these.
Many East Asian scripts are traditionally written vertically rather than horizontally. Some of the conventions of ruby text stem from this tradition. Furthermore, with Chinese Bopomofo/Zhuyin-Fuhao, the ruby annotation may traditionally run vertically next to each character even for horizontal text (example from the CSS3 ruby spec):

Note that as shown in the above example, this is complicated by the fact that tone markers are not to be rendered in the normal vertical text stream, but to the side of it.
Unfortunately, vertical text does not lend itself easily to seamless integration with the way web pages are rendered today. Addressing this shortcoming would not only help further improve the visual quality of ruby, but open up ways to give East Asian web pages a more natural look. However, implementation of this is a challenge that still lies ahead.