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
_______________________________________________
webkit-qt mailing list
webkit-qt@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
