[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.
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?
Simon
More information about the webkit-qt
mailing list