Qt & V8

  • My apologies if the answer is out there, but poking around I'm finding a lot of conflicting responses.

    The top results say V8 support was coming but was then abandoned, and yet "What's new in Qt 5" clearly says Qt is using V8:

    And then the latest 5.2 announcement says, "While the new engine is somewhat slower than V8 when it comes to pure Javascript performance". New engine? New versus what? This implies they switched back to JSC from V8? Or something else?

    I've elsewhere heard it suggested that QtWebKit proper always stayed on JSC but QML went to V8 and is now dropping back to JSC.

    At any rate, having trouble finding a straight answer. Can anybody clarify?

  • Qt 5.2 is using the V4 engine as I understand it.

  • Er. V4? Do you mean V8? Why then does their 5.2 announcement talk about a "new engine" that is "slower than V8" (http://blog.qt.digia.com/blog/2013/09/30/qt-5-2-alpha-available/)?

    Ugh. Why is this so poorly documented? =(

  • Moderators

    If you want to really know what is going on, follow the development mailing list :)

    V4VM is the new engine and it will replace V8 in QtQML in Qt 5.2. It's a custom implementation of ECMA that is - indeed - a bit slower when it comes to parsing long JS scripts, but is several orders of magnitude faster than V8 when it comes to expressions most often used in QML: property bindings, small assignments, etc.

    This is poorly documented because Qt developers do not need to know any of this. They are meant to be using C++, QML and JS, regardless of what the backend actually is :D

  • Moderators

    Qt 5.0 started using V8 because it was vastly superior to the engine used in Qt 4.8.

    However, it still wasn't perfect. V8 is designed for web browsers, which have different requirements to QML applications, like what sierdzio described. The upstream V8 maintainers wouldn't accept patches that benefit QML, because those patches won't benefit browsers (which is perfectly understandable).

    So, to take QML to the next level, V4VM was born -- a JavaScript engine that is fully optimized for QML and that has all of Qt's interests at heart. You can read more of the technical details at http://blog.qt.digia.com/blog/2013/04/15/evolution-of-the-qml-engine-part-1/

    Note: Qt WebKit is a browser toolkit, so it would continue to use a browser-optimized JavaScript engine, not V4VM.

  • Thanks for all the info!

    JKSH: When you say Qt 5.0 started using V8 -- does that mean in QtWebKit and QML or just QML?

    sierdzio: I contest that Qt developers do need to know all of this, because the backend affects behavior (especially memory and performance) of the JS. It'd be great if it really were drop-in simple and ignorable, but we're not there yet. In any case, where would I go to follow said development list?

  • Moderators

    You're welcome. :)

    Only QML used V8. Qt WebKit experimented with V8, but it never became official: https://bugreports.qt-project.org/browse/QTBUG-13184?page=com.atlassian.streams.streams-jira-plugin:activity-stream-issue-tab

    Upstream, the WebKit Project has decided to completely drop V8 support: https://lists.webkit.org/pipermail/webkit-dev/2013-April/024447.html

  • Moderators

    zeveck then we disagree :) Even if you know what is the backend, you can't change it, so the information - although interesting - is of little practical use. If there is anything that you as a developer need to know, the documentation will tell you (there is, after all, a doc page named "QML performance", which lists some optimisation tricks for QtQuick).

    You can find all information on Mailing Lists here: "link":https://qt-project.org/contribute, or to be more specific, "here":http://lists.qt-project.org/mailman/listinfo.

  • True about WebKit dropping V8, but as I understand it Qt is going to wend towards Chromium, which I assume will bring V8 along since I don't think Chromium supports JSC? (Though the blog post makes the move towards Chromium clear, it doesn't actually address V8.)


    sierdzio: Thanks for the links!

  • Moderators

    Qt WebEngine will probably use whatever JavaScript engine is in the upstream Chromium project -- I doubt there is a good reason to spent many months ripping out the built-in engine and transplanting a different one.

    But if you want real insider information on technical details and roadmaps, subscribe to and ask at the Development mailing list -- that's where Qt's engineers live. This forum caters more for questions on how to use Qt.

  • I can definitely see the reasons for this change. Having spent hours reading the code in the current implementation it is obvious that many things should be done differently.

    The problem is that QML doesn't really provide proper ways of extending the functionality of the JavaScript engine. The old QScriptEngine API had pretty good support for extensions, but even in Qt 4, QDeclarativeEngine hid these as implementation details. The only way to really extend QML was to hack the private API and hope nothing changes.

    With Qt 5, the same problem persist. The extension interfaces are not only incomplete but also broken in many ways. All this makes it practically impossible to write JavaScript extensions to QML. The only use case that has good support is UI components implemented by deriving QQuickItem.

    Consequently, I have needed to hack my extensions by using hidden low-level APIs. In Qt 4, this was just a matter of finding a pointer to the internal QScriptEngine, which was used to execute QML code. In Qt5, I have used the v8 API directly. I have to say I'm disappointed I need to do this once again with Qt 5.2.

  • Moderators

    [quote author="topiolli" date="1382519308"]Consequently, I have needed to hack my extensions by using hidden low-level APIs. In Qt 4, this was just a matter of finding a pointer to the internal QScriptEngine, which was used to execute QML code. In Qt5, I have used the v8 API directly. I have to say I'm disappointed I need to do this once again with Qt 5.2.[/quote]

    Please rise this issue on dev ML. I don't think your use case is being considered by people working on QML, they may be interested in knowing that you need some more stable JS extension APIs.

Log in to reply

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.