What's being used under the hood in Qt 5.0.1 QWebView
-
I think this should be straightforward but I can't seem to find documentation that spells these things out clearly...
I have downloaded Qt 5.0.1 and I'm building it on Windows. I plan to build a simple example C++ app with a QWebView within it. When I run this:
Is WebKit or WebKit 2 being used? Is there any way I can tell?
Is JavaScriptCore or V8 being used? Is there any way I can tell?
Is the Chromium API found in the source tree at qtwebkit\Source\Platform\chromium being used? How can I tell?
Are all of these things compile time settings, or runtime settings, or just automatic?
As I have said, I have already searched documentation to try to find answers to these questions, but other than the 'what's new in Qt 5' page, I've really found -nothing- that talks about distinctions between WebKit and WebKit 2, JavascriptCore and V8, and Chromium.
Thanks,
Stan -
I ran the SunSpider benchmark in a Qt4.7 and a Qt5 QWebView and get (more or less) identical results. That leads me to believe that either my build of Qt5 doesn't use V8 - which I assume to be faster - for the QWebView or that Qt5 in general does not. Could anyone clarify?
-
Hi,
So there are two things. There is the QWebView and the QQuickWebView.
The QWebView is widgets based and uses WebKit1.
The QQuickWebView is for use with Qt Quick, and uses WebKit2.Now just to be clear, WebKit2 is NOT WebKit version 2. It is just the name for WebKit with a process separation as in a WebProcess for doing networking and rendering and a UIProcess for actually displaying the previously rendered content.
WebKit uses JavaScriptCore. V8 is only used for QML! But even then the javascript code within WebKit (the WebView) will be executed in JavaScriptCore.
About the Chromium API, the simple answer is: No, we are not using it.
There are no settings for that. The choice that you have is to use Widgets+QWebView or QML+QQuickWebView.
- Zeno
-
Hi Zeno,
just wondering out loud, that it might be interesting to have a blog post or a link to an email for the curious among us wondering like me about the way forward. I'm assuming some efforts are being made so in a future version we will not use multiple engines, and what the main blockers are.
Thanks!
-
Hi Thomas,
Well the current situation with two engines is rather unfortunate i agree. Then again it shouldn't really bother a user which js engine is being used behind the scene. - But yes of course, I see your point and I agree.
I assume that there will be a blog post or an email at the appropriate time by the appropriate people. :-)