[webkit-qt] webkit2, v8, diplomacy

Simon Hausmann simon.hausmann at nokia.com
Wed Jun 13 08:44:31 PDT 2012

On Tuesday, June 05, 2012 02:53:19 PM ext Balazs Kelemen wrote:
>      Hi all!
> I think it's time to decide how important is the v8 integration for us.


> I'm not saying it's hyper-super important, I'm just curious about your
> opinion. In fact we have a qt5 release blocker bug for that:
> https://bugs.webkit.org/show_bug.cgi?id=76778 (although at the time when
> it has been filed we did not expect that much community resistance) and
> it's also quite clear that this could save a lot of memory (1 js engine
> instead of 2). 

I would say that the aspect of memory savings disappeared the moment QtQuick1 
became a separate module that continues to use QtScript and we decided to use 
WebKit2 for the QtQuick2 integration. The process separation means that the 
two engines live in separate processes spaces and the only memory served would 
be on disk storage and the memory mapped pages from the shared library.

> It's evident that we don't want to go against the
> community, but still I think they should be more open to this. 

I agree here, and I am disappointed to see such a strict response against 
giving us a choice for WebKit2.

> It's
> really just some lines of boilerplate glue code to webkit2, and we
> choose a solution that provides source compatibility with
> WebKitTestRunner. Btw, there are the bugs:
>      - https://bugs.webkit.org/show_bug.cgi?id=76778 (meta)
>      - https://bugs.webkit.org/show_bug.cgi?id=87872
> <https://bugs.webkit.org/show_bug.cgi?id=87872>shim for wtr
>      - https://bugs.webkit.org/show_bug.cgi?id=84457 wk2+v8
> If the case is that we want to go for this, I would definitely need your
> help to get community acceptance since I'm not a reviewer and honestly I
> am not very good in diplomacy :)
> Anyway, I would not like to make the false illusion that pushing these
> patches will solve every problem and just save memory. In fact, in order
> to get the desired benefit we have to solve other issues:
>      - using the same copy of v8 (fork) in declarative and webkit. this
> is tricky because webkit needs the most up-to-date v8 version

And it seems that this a bigger issue as originally estimated.

>      - using v8 in qtscript, or detaching qtscrpit from qtdeclarative (I
> heard qtscript is a dependency)

I don't think we have to worry about QtScript, it is not a link time 

Summarizing: The big original motivation behind using V8 in QtWebKit was based 
on the idea that Qt would use one JS engine for QML and WebKit, resulting in 
less memory usage and really interesting possibilities of efficiently exchanging 
information between web content and native code in hybrid applications.

This motivation was built around two assumptions:

    1) QML uses V8 extensively
    2) QML and WebKit would live together in the same process space

In the past few months we've seen changes in the Qt architecture as well as on 
our WebKit side that change things a little:

    1) QtQuick1 and QtQuick2 are separate modules, the former using QtScript 
(old JSC fork) and the latter using V8 right now. Note that QtWebKit in Qt 5 
will link against QtQuick2, but not against QtQuick1. (The QtQuick1 WebKit 
support will move into the QtQuick1 module)

    2) We decided to use WebKit2 with process separation for the QtQuick2 
integration. Any communication tight communication between the two in terms of 
information exchange between web content and native code would probably go 
through the existing SerializedScriptValue bridge that - given a difference in 
engine on both sides -  would probably end up using JSON as data format.

Coming therefore back to the original question of how important the V8 
integration is for us: Combining the above with with the rather harsh response 
from the community against us using V8 in QtWebKit makes me think that it is 
much less important than it seems.

I honestly feel pretty bad for Balazs because of the response you received on 
your (great) efforts on coming up with a maintainable solution that would allow 
us to choose V8.

What do the others think?


More information about the webkit-qt mailing list