Ying Tong Iddle I Po

Relating to an earlier post on indirect/off-screen rendering with Qt. There is a post on the Qt labs blog that is interesting. I’m not just posting this so I remember to read it properly later, honest!

Fail

Via reddit:

This weekend I became the proud owner of a new shiny, a Nokia N810. This isn’t a mobile phone but it is an ‘Internet in My Pocket’ which can use my existing phone to connect to teh Intertubes. It is also eminently hackable being as the complex procedure required to become root is to open the included terminal emulator and use sudo.

A post will appear in due course about the pros and cons of the device as I get familiar with it but, for the moment, I’m terribly pleased with it.

A slight niggle is that the included (Gecko based) web browser is a bit slow. ‘Slow’ is a word which has many nuanced meanings in UI design of course. More correctly, I mean the UI has a high latency, especially when scrolling. I suspect this is due to rendering being done in the main GUI thread. This is fine and dandy for desktop use. Indeed some toolkits don’t allow rendering in anything other than the GUI thread[1].

In contrast, mobile Safari is a pleasure to use. I suspect the main reason for this is that mobile Safari prioritises UI feedback above all else. In addition, it appears to use a thread to render the page off-screen into a buffer and composite it later. Should the rendering not be completed when some area needs displaying, it shows a default ‘checkerboard’ pattern. The upshot of this is that although rendering itself may be as slow or slower than the N810’s browser, the overall feel is of a snappier, more responsive UI.

Identifying an itch is in itself useless without scratching it. “Hmm,” thinks I, “this might be a nice easy little app to get myself into the Gtk-based UI of the N810.” I naively thought that WebKit would be the answer to all my prayers. After all, it is the engine behind the mobile Safari browser which I wish to emulate.

It turns out that WebKit is, unsurprisingly, not the panacea that I had hoped. This is not, I should say, a fault of WebKit, per se, merely the platform ‘ports’ which are available.

The concept of a ‘port’ in WebKit is somewhat abstract. Each subsystem in WebKit, be it rendering, chrome, drag and drop, network access, etc, is abstracted. For example a ‘GraphicsContext’ which is used for rendering may be backed by a Qt QPainter, a Cairo context, a CoreGraphics context or whatever. Similarly the logic for handling popups, etc is hidden behind a ‘chrome’ layer. A ‘port’ is a set of these abstractions which work together all hidden behind a platform-specific interface layer which maps WebKit’s abstraction of pages, frames and views into a particular toolkit’s object system.

For example, the Gtk port makes use of Cairo for graphics, Gtk for chrome, libcurl for networking and presents a GObject interface and a GtkWidget-based ‘WebView’ class. The Mac port uses CoreGraphics and CoreFoundation and presents a Objective C Cocoa interface.

The port which is of interest to those of us explicitly wanting to do deferred off-screen rendering is the Qt port. The Qt port’s interface makes explicit the separation between a web page, being a portal through which the user looks at the web, a nested tree of web frames within that page and a web view which provides a view onto a web page.

Each frame, whether it be chrome, HTML or a plugin, knows how to render itself to a QPainter and each page emits signals when redraw is requested and accepts abstract input events (such as ‘user followed link X’). In this model the web page layout and interaction is formally separate from the rendering. The Qt QWebView widget connects the page’s redrawRequested to a handler which creates a QPainter onto the widget and calls the page’s main frame’s render method with that QPainter. Aside from some input event marshalling, that is pretty much it.

This model is ideal for my purposes. Simply create a set of off-screen image-backed tiles which act as a ‘rendering cache’ and connect the redrawRequested signal to a handler which prods another thread to create a QPainter onto the image and render the tile’s contents.

There are two problems:

• This is Qt, not Gtk. This is not necessarily too bad given that Nokia is almost certainly going to move to Qt for the future.
• The QtWebKit port uses QPixmaps which cannot safely be used outside of the GUI thread.

The second problem is the most annoying. What I want for my needs is a version of the Gtk/Cairo port which has the same separation as the Qt port. This shouldn’t be too hard to hack together, should it? I’m hoping that, as long as the webkit event loop and tile rendering stuff live in the same thread, the actual sum total of webpage rendering and logic can be moved out of the GUI thread.

This grand plan is currently scuppered by the inordinate amount of time it is taking for bzr to check out a version of the WebKit SVN.

[1] This is not true of off-screen rendering into a QImage, but QtWebkit uses QPixmaps internally which screws any out-of-GUI-thread rendering one may want to do.

I saw the following out of the corner of my eye on the BBC news ticker and wondered what Patrick Troughton did in the last years of his life…

“Second doctor who saw Baby P before his death is suspended”

Until the headline had been ticker-taped out fully, I was most mystified.