Making QtWebKit with WebKit2 in Qt 5.0 work on Raspberry Pi

After compiling Qt 5.0 for Raspberry Pi, I wanted to try all the modules. I compiled and tested the simplest modules first, like:

1. qtbase
2. qtdeclarative
3. qtjsbackend
4. qtquick1
5. qtscript
6. qtxmlpatterns

Everything worked quite smoothly, without any change, except the patch to the v8 engine in qtjsbackend module for ARM hardfp (read here).

I then turned my attention to the QtWebKit module: I know that many changes have been applied to this module for Qt 5.0, so it is very interesting to try it. Therefore, I started to build it the usual way:

cd your_qt_sources/qtwebkit
your_qt_prefix/bin/qmake
make -jn
make install 

Unfortunately, at the moment of writing, it didn’t work for me: the module compiled and linked successfully, but crashed almost as soon as the page load procedure started. I therefore had to start searching around and asking Qt guys about this issue, and during this, I was frequently directed here. Turned out this is exactly the issue I encountered: I applied the latest patch (consider reading the entire report and check that a more stable fix is available):

cd your_qt_sources/qtwebkit
patch -p1 < ~/webkit_patch

where webkit_patch is the linked diff. So, now you can compile the module to include the differences and try again. Consider that the patch seems to be near land, so it might not be necessary for you in the future. As a first test, this is the code I tried:

#include <QApplication>
#include <QWebView>
#include <QUrl>

int main(int argc, char* argv[])
{
    QApplication app(argc, argv);
    QWebView webView;
    webView.setUrl(QUrl("https://stackoverflow.com/"));
    webView.show();
    return app.exec();
}

At this point, it should work. As you can see, performance is unacceptable. This is not the way an embedded browser is supposed to work indeed, this is more like classes that can be used for a desktop browser.
Next step was testing WebKit2 with tiling and all that nice stuff. So I tried to create a simple application loading a WebView QML element, like this:

main.cpp:
#include <QGuiApplication>
#include <QQuickView>
#include <QUrl>

int main(int argc, char *argv[])
{
    QGuiApplication app(argc, argv);
    QQuickView viewer;
    viewer.setSource(QUrl("/home/pi/main.qml"));
    viewer.show();
    return app.exec();
}

main.qml:
import QtQuick 2.0
import QtWebKit 3.0

WebView {
    url: "http://www.cnn.com"
    x: 100
    y: 100   
    width:  1500
    height: 900
}

When I tried this the first time, it closed with an anonymous error on QtWebProcess:

Failed to start " QtWebProcess 14"

After looking into the sources, I found this is simply a failure to find the QtWebProcess binary. It is needed because WebKit2 uses a separate process to draw the content. Placing it in /usr/bin is sufficient:

cd /usr/bin
sudo ln -s your_qt_prefix/bin/QtWebProcess QtWebProcess

Or better use a relative path. Now what you might get is… nothing at all… At least this is what I got. After some seconds a crash occurred and often nothing was drawn.
It took me some time to guess what was happening: it seems that QtWebKit is trying to draw with 32 bit color depth, while instead the rest of Qt is rendering using 16 bit color depth (especially if you’re using the eglfs platform plugin) on a RGB565 EGL configuration.
According to the Qt WebKit code, it seems that the entire code is assuming 32 bit color depth is being used, and this is hardcoded instead of negotiated with the main process. As a quick fix, I made the entire EGL configuration to be 32 bit (read this).
By setting this, it is possible to make QtWebKit work in 1080p with 32 bit color depth. If I’ll find the time I’ll do the needed modifications to have the same configuration with the correct color depth.

Consider that, at the moment of writing, the configuration of the wheezy image does not assign sufficient memory to the GPU.You’ll see therefore pages where many tiles are black: that is the result of insufficient GPU memory when trying to allocate for the texture. Just assign some more memory to the GPU editing the /boot/config.txt file of your Pi.

Sample Video

NOTE: For updated information read here.