[webkit-qt] webkit2, v8, diplomacy

[Balazs Kelemen]

On 06/13/2012 05:44 PM, Simon Hausmann wrote:
> 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.
> Yes.
>
>> 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
> dependency.
>
>
> 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?

Thanks for this clear summarization. Given you arguments and the fact 
that we got a negative community feedback, I think it's quite clear that 
the way to go on is keep using JSC in the web process which is not that 
bad with process separation.

Anyway, this v8 experiment was quite an exciting one