read more

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.

Working on what matters

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.

How we benchmark WebKit

The performance suite has three kinds of tools:

• host tools: to manage the data used by the benchmarks
• tests: the benchmarks
• reductions: some benchmarks for specific components of WebKit

Let’s have a look at the tools and the tests. The full documentation of the performance suite is on the WebKit’s wiki.

Mirroring the web

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.

Using the benchmarks

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:

• the page loading performance (with or without rendering)
• the rendering performance
• the scrolling performance

How you can use that?

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:

• Janne added the necessary meta-data to make QtWebKit play nicely with Symbian backups (34077).
• I did some code cleanups in RenderThemeQt and fixed a bug with combo boxes not showing up in Maemo5 (34088).
• Holger fixed a regression in the JavaScript prompt handling (30914).
• Jedrzej landed the first files for building QtScript on top of JavaScriptCore’s C API (32565).
• Diego added history support to the Qt DRT, we now pass the http/tests/history layout tests! (34167)
• Daniel fixed a bug with the height of button elements (29564).
• Kent fixed support for ES5 style introspection with QMetaObject methods (34087).
• Yael implemented the Qt part of WebSocket support, we now pass websocket/tests in the layout tests (34180).
• Diego fixed more worker layout tests by adding support for counting worker threads in the Qt DRT (34221).
• Holger found a neat way to speed up the conversion from KURL to QUrl (33873).
• Trond fixed an endless loop in QWebPage printing (r53997).
• Kenneth fixed incorrect fonts on comboboxes on Maemo5 and Symbian (r53999).
• Andreas upstreamed Ralf and Robert’s kinetic scrolling support for QWebView using QAbstractKineticScroller (34267).
• Benjamin implemented support for the display() method in the Qt DRT (34258).
• Oswald speed up the conversion between WebCore::String and QString by avoiding QString::fromUtf16() (r54060).
• Kenneth landed a patch to disable auto-uppercasing and text prediction for password input fields (r54064).
• Kenneth also continued to clean up the QtLauncher for a future merge with QGVLauncher
• Andreas and Kenneth submitted tweaks to the look’n'feel of QtLauncher on Maemo5.

read more

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:

• Tor Arne has ported the Qt build of DumpRenderTree to run on Windows. (r53526, r53543).
• Luiz continued with cleaning up the combobox popup handling.(33418).
• Ben from the Google Team fixed a bug where touch events weren’t sent to iframes (33894).
• No’am landed support in the Qt bindings that allows passing pixmaps and images as arguments in signals/slots/properties, which can then easily be turned into image elements or data urls. (32461).
• Benjamin cleaned up the QWebPage autotest (32216).
• On Thursday we landed No’am’s implementation of GraphicsLayer. This accelerates the composition of layers with animated opacity or transform attributes, through content caching in pixmaps. Layers are mapped to 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).
• Diego continued implementing missing functions in the Qt DRT (33945).
• Jakub fixed a crash with video elements and phonon (33842).
• Girish fixed a bug with combobox popups in transformed QGraphicsWebViews (r53703, 33887).
• Robert fixed 5 layout tests by fixing support for window.close() and window.closed() in the Qt DRT (32953).
• Kent fixed bugs with Object.getOwnPropertyDescriptor (33948, 33946).

Introduction

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.

Ruby Tags

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:

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:

Current State and Future Improvements

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.

CSS3 Specifications

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.

Ruby module

This is the main module concerning ruby.

Requirements on Japanese Text Layout

Has sections on ruby (probably more than you will ever want to know about ruby rendering), as well as general rendering guidelines for Japanese.

Line module

This module specifies the line-stacking-ruby property.

Text module

Although only marginally related to ruby, this contains additional rules for CJK line breaking.

Vertical Text

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.