[webkit-qt] QtQuick QML API for WebKit1

[Simon Hausmann]

On Wednesday, February 13, 2013 04:47:55 PM Alberto Mardegan wrote:
> Hi all!
>    I plan to spend some time on building a QtQuick (Qt5) plugin for WebKit1.
> There are several reasons why I want to do this, the main ones being the
> possibility of playing with the cookie jar and having direct access to the
> DOM.
> It should also make sense for people who need just a quick web renderer
> and don't need the split-process design (for instance, for a help
> application rendering local content).
> 
> I'm basically writing this e-mail FYI, and of course to collect early
> feedback (let me know if you see any sense in this effort, or whether
> you welcome it).

I'm going to use the opportunity to give some feedback :)

You may observe a trend out there in the way WebKit is used nowadays: The core 
engine has a tendency to run on a separate thread (iOS) or a separate process 
(Safari, Chromium), even when embedded in applications. 

The core engine is running in one big fat event loop that is slowly breaking 
apart. Efforts are underway to move HTML parsing into a separate thread, the 
networking is usually already on a different thread (or even process) and the 
web developers are starting to move heavier scripts into the more widely 
available JavaScript workers. Nevertheless what remains is still a big event 
loop that is very easy to stall by simply not returning to it quickly enough.

The fact that QtQuick2 tries to move the GL rendering into a separate thread 
also helps here, but it's not a catch-all solution, especially not if we want 
to continue to make it easy for developers to write things in a synchronous 
way in the main event loop and we do the other heavy processing elsewhere. 
(i.e. us not getting into the way of the application developer)

It is simply in the nature of the web as a platform that in an onclick handler 
you can do whatever you want however long you want and nobody can stop you. 
That API isn't going to go away anytime soon and I don't think that it the 
behaviour can be changed without breaking half of the web out there :)

However at the same time the users out there have higher expectations than 
ever towards the speed of computers, and that mostly refers to perceived 
responsiveness.

That I believe is the primary motivation towards the established model of 
separating WebKit into a thread or process. It is a clear trend within the 
project and its users.

There are only two ways of using WebKit that way, WebKit2 or Chromium. We have 
chosen the former, along with the other communities (our friends from EFL and 
Gtk+ for example).

For compatibility we do have to keep the single-threaded WebKit code paths 
around (aka QWebPage/QWebView in Qt), but with my Qt project module maintainer 
hat on I would welcome efforts to _reduce_ the maintenance of that instead of 
adding to it. We should streamline our efforts and work on the same things.

Consequently with that information at hand I'm not in favour of having a 
QtQuick2 integration that is based on the single-threaded WebKit in the 
upstream source tree. We need some better arguments on the table :)

As mentioned in earlier mails, I would much rather welcome efforts to make the 
use-cases work that you're interested in in the world of WebKit2. There's 
nothing inherent in a process separation that makes things like DOM access 
impossible. It just works slightly differently. For example by writing the code 
to traverse the DOM in JavaScript and running it as part of that big event 
loop. Extract the information you need and pass it back to the application.

I recently learned that the KDAB folks apparently have had success with doing 
simple QObject bindings across process boundaries. With reasonable contraints 
that are documented (properties would be value cached, so don't expose heavy 
content for example) that might be a workable alternative to make hybrid use-
cases easier.



Simon

> Though I didn't dig very deep so far, my understanding is that I cannot
> implement this as a completely separate module, but I'm afraid it will
> have to be part of the webkit source tree (and share a lot of code with
> the QtWebkitWidgets module). So suggestions on how to handle this are
> very welcome.
> 
> I didn't write any code yet, and I probably won't start before 1-2
> weeks, but if anyone is interesting in helping me out please drop me a
> line. :-)