New Qt WebKit nearing release

So, for the first time, we are going to release Qt WebKit as a separate project. This does not mean that we will stop releasing it as part of Qt, but that if you are stuck on an older Qt 4.6 release, it is still possible to use a newer Qt WebKit. In the future this also allows us to release more often, independently of Qt.

The last half year we have been hard at work on enabling the use of Qt WebKit on mobile devices, while still supporting and maintaining our brilliant support of Desktop applications. Targeting mobile devices is an ongoing challenge due to other interaction modes, smaller screen sizes and less powerful processor.

We have been growing our teams and our responsibilities and it has been an interesting, if not tiring, half a year :-) Locally, we have been growing our Brazilian core team to 5 people, plus creating some new teams working on related projects. What a rush! :-) We now have teams in at least Norway, Finland, Brazil and Boston working directly on WebKit.

So what have our distributed teams been up to?

Well, Qt WebKit has always felt reasonable fast on the Desktop. Not top in the class, but working quite well. On mobile devices the story was very different; dog slow, barely usable! Lots of time has gone into improving that situation by doing profiling and hunting down performance bottlenecks. Improvements that also help the Desktop case. We are not done yet, but our upcoming QtWebKit 2.0 release is a major improvement. Combining QtWebKit 2.0 with the upcoming Qt 4.7, are you will even get a few extra optimizations for free.

Sometimes we had to make more drastic changes, such as using tiling for archiving good scrolling performance. Tiling basically means that you don't paint directly to the screen, but instead to surfaces (which then can actually benefit from hardware acceleration). When scrolling you then move/blit these tiles. The standard way of doing scrolling, is that you copy an area and move that area, but you always have to paint the new area visible. With tiling you normally update a few more row of tiles than those visible on the screen, so when moving you do not always need to repaint. Repainting can actually mostly be done when you are idle.

We also experimented with rendering the tiles in another process, so that scrolling would never be blocked by loading or painting, but with the downside than when there is no tile painted, a checkerboard pattern would be shown, very similarly to the iPhone. Getting this right is a lot of work and with the announcement of WebKit2, we decided to postpone it for now and later concentrate on WebKit2 instead, as that will bring similar benefits, a.o.

Tiling helps with the mobile interaction model, as it is quite fast to zoom. Zooming basically scaled the tiles and then re-renders, which can be done with a smooth animation. Unfortunately, just as on the iPhone, we cannot support fixed elements, so if page authors really need that, they will have to go for CSS3 Transformations which with accelerated compositing will be painted as another layer on top of the tiles.

Which brings me to the next feature: accelerated compositing. Some of the new CSS3 features such as animation and transformations were created with hardware acceleration in mind, for instance the CSS 3 transformation live in another coordinate system, and thus animating a transformation change does not change any DOM values such as for instance 'left'. The idea is that the elements being transformed are painted as a separate layer, composited on top of the normal web contents. On the iPhone, this is implemented using CoreAnimation, I believe, and is thus, tied to hardware support. For Qt, we implemented it on top of out Graphics View system, which means that even when the Graphics System is not being accelerated by hardware, we will archive better performance due to caching of the painted elements. Pretty cool stuff. Unfortunately, just as with tiling, it is only possible to take advantage of this new feature if you use the QGraphicsWebView and not the older brother, QWebView.

You can imagine that most web sites were written for a width a lot larger than what you find on most phones, so either you can show the page in its original size and you will have to scroll a lot, or you can zoom it out to fit within the width of the page. The latter makes it impossible to read the text, so instead of laying out to the size of the width, we have new API (actually originally introduced in Qt 4.6) that makes it possible to lay out the contents as it was having a different viewport. The iPhone and Android does the same, using a value between 800 and 1008 pixels (980 is always default on the iPhone, where as Android varies). Laying out with such a width makes the site's contents still readable most of the time, without breaking the layout. To give the page authors a bit more control over this, Apple introduced a meta tag called "viewport", which is now supported by most mobile browsers, including Mozilla Fennec. This tag allows the site author to specify which width should be used for laying out the contents as well as which zoom factor should be used, and within which limits.

As touch is becoming standard on cell phones, we also had to make a few other adaptations. For instance sites with frame sets are mostly useless due to various scrolling sub elements; the same count for sites with iframes. What most mobile browsers do to fix this, is to apply frame flattening, which we now also supports/ Originally a feature invented by Nokia, but first really being put to good use on the iPhone and on Android.

We didn't leave out non-touch phones either, and as such implemented spatial navigation (aka. keyboard navigation), which is not only useful for cellphones with keyboard only, but also by tv's and set-top boxes.

Not everything has been related to mobile though, and as such our teams have been working on implementing new HTML5 elements such as the Progress element and concentrating on some CSS features and DOM features, such as DOM Level 3 CustomEvents, 'view-mode' Media Feature, as well as some features from CSSOM Views making it possible to listen to media and media feature changes; very useful for creating Web applications.

Wow, it has been a loooong half year it seems! Now time to prepare for our local release parties! :-)