Announcement

Collapse
No announcement yet.

KDAB Working On Embedding Servo Web Engine Within Qt

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • lowflyer
    replied
    Originally posted by anda_skoa View Post
    Of course it is.
    For any comparison you want to rule out any other contributing factors as much as possible, so anything that can be done with the same means will be done with the same means.
    I'm not sure whether we talk the same language here. If you remove *every* *other* *factor* and only compare the same things - you'll never see any difference. You just ruled out the factors that make a difference.

    Originally posted by anda_skoa View Post
    I am not suggesting a mix of QtQuick and QtWidgets, but testing both with the same underlying stack.
    Same OS, same compiler, same Qt version, same test data, same application setup.

    Otherwise you won't know which of the different outside the UI technologies has contributed to any difference in measurement.
    If you are to compare a bulldozer with a Porsche and you only look at the choice of metals, the number of seats, the number of pistons and the power rating of the engine, you'll end up with the conclusion that "both are practically similar". Good luck at digging a trench with your Porsche!

    Compare different UI technologies - not: "the same technologies". Cut out everything of QtQuick and QML from the QtWidgets application and - vice versa - everything QtWidgets from the QML application. Don't burden one side with the work of the other side.​

    I can agree with:
    • Same OS
    • Same compiler
    • Same Qt version
    • Same test data
    I cannot agree with:
    • Same underlying stack
    I would add:
    • Same functionality
    • Same look
    • Don't "cross use" the different technologies

    Leave a comment:


  • anda_skoa
    replied
    Originally posted by lowflyer View Post
    That's exactly how not to do it.
    Of course it is.
    For any comparison you want to rule out any other contributing factors as much as possible, so anything that can be done with the same means will be done with the same means.

    Originally posted by lowflyer View Post
    If you actually want to compare UI technologies you'd have to compare a QML / QtQuick application with a C++ QWidget application - not two mixes of each other.
    I am not suggesting a mix of QtQuick and QtWidgets, but testing both with the same underlying stack.
    Same OS, same compiler, same Qt version, same test data, same application setup.

    Otherwise you won't know which of the different outside the UI technologies has contributed to any difference in measurement.

    Leave a comment:


  • lowflyer
    replied
    Originally posted by anda_skoa View Post
    Comparison of UI technologies can also be done without mixing other things into the evalutaion.

    If one were to compare QtQuick and QtWidgets one would either create the QtQuick object tree in C++ or create the QtWidget tree through QML.
    That's exactly how not to do it. If you actually want to compare UI technologies you'd have to compare a QML / QtQuick application with a C++ QWidget application - not two mixes of each other.

    Leave a comment:


  • anda_skoa
    replied
    Originally posted by lowflyer View Post
    You say QML got WebKit's V8? ... A web engine? -- This is *exactly* my initial point.
    V8 was WebKit's JavaScript engine and is not a web engine.
    It is also used by NodeJs, and probably other projects that needed JavaScript capabilities.

    In any case not relevant anymore since QML not has a new engine implementation that does not use anything from WebKit anymore.

    Originally posted by lowflyer View Post
    The replacement V4 - you even call it "engine" - per definition has to replicate its predecessor.
    The concept of an engine is used in various contexts, in software and hardware.
    It does not imply web engine.

    V4 was specifically created as a QML engine, to avoid going into the script part as much as possible.

    Partially due to limitations on certain platforms regarding non-system JS interpretation (or the absence of JIT compiling).
    Partially to improve performance and avoid type conversions.
    Partially to enable use cases in which scripting is not possible at all, for example Qt for MCU.

    Getting rid of any remnants of things V8 might have had for web work is a nice bonus. Reduced the memory consumption quite considerably.

    Originally posted by lowflyer View Post
    While lowlevel comparisions have their value, I was thinking of directly comparing two "as similar as possible" GUI applications.
    In such a case it would be very difficult, if not impossible, to attribute any differences to each of the involved parts.
    Better to have otherwise identical objects and measure really the overhead of the QML bindings.

    Originally posted by lowflyer View Post
    My whole aim in this discussion is to point out that the QML engine is burning up your precious CPU cycles.
    And to measure that one needs to compare with otherwise equal code.

    Originally posted by lowflyer View Post
    It is interesting to see that you outright dismiss an overall compare between UI technologies.
    Not at all.
    Comparison of UI technologies can also be done without mixing other things into the evalutaion.

    If one were to compare QtQuick and QtWidgets one would either create the QtQuick object tree in C++ or create the QtWidget tree through QML.

    Leave a comment:


  • lowflyer
    replied
    Originally posted by patrick1946 View Post

    If you make the root struct a global variable there is no need for a heap. That is why it loads so fast. There are not myriad of heap allocations. Especially because there is no PIMPL. Most of the limitations comes from the low end hardware and the design scope. The principle iis much more powerful.
    So, like anda_skoa , you also divert the discussion away from the original topic "KDAB embedding Servo engine into Qt".

    Well then, lets discuss "Qt for MCU" now.

    Unless you put the whole object tree statically into that global variable, you will have heap allocations. Depending on how you code you will probably also want to make it const to further prevent allocations.

    Side notes:
    1. using global variables is bad style
    2. heap allocations are usually not the main driver of bad performance
    3. making the object tree static and/or const will significantly reduce its flexibility
    4. PIMPL has nothing to do with any of that
    5. big global objects are not "for free". You'll pay for it with either bigger binaries or longer initialization time or bigger memory usage or all three combined.

    Leave a comment:


  • patrick1946
    replied
    Originally posted by lowflyer View Post

    Side note: even structs need to be allocated somewhere.

    "Qt for MCU" is a different animal entirely. anda_skoa tried to divert the discussion there. It's a rather limited subset of QML and Qt Quick despite having some interoperability. There are quite stringent limitations on the hardware and don't forget the vendor-lock-in situation.
    If you make the root struct a global variable there is no need for a heap. That is why it loads so fast. There are not myriad of heap allocations. Especially because there is no PIMPL. Most of the limitations comes from the low end hardware and the design scope. The principle iis much more powerful.

    Leave a comment:


  • lowflyer
    replied
    Originally posted by patrick1946 View Post

    There is Qt for MCU which is using a QML dialect to directly create structs. So no heap allocations for QObject anymore. They should have gone that route from the beginning. Slint is using actually the same approach(it is done actually be the same people who started Qt for MCU).
    Side note: even structs need to be allocated somewhere.

    "Qt for MCU" is a different animal entirely. anda_skoa tried to divert the discussion there. It's a rather limited subset of QML and Qt Quick despite having some interoperability. There are quite stringent limitations on the hardware and don't forget the vendor-lock-in situation.

    Leave a comment:


  • patrick1946
    replied
    Originally posted by lowflyer View Post
    Dear anda_skoa ,

    Your personal iron-clad definition of what a web engine is makes it impossible to get the slightest point through to you. It makes it *very* difficult to even communicate with you. It is not helpful to assume the other extreme if you disagree.

    You contradict yourself:

    You say QML got WebKit's V8? ... A web engine? -- This is *exactly* my initial point.
    The replacement V4 - you even call it "engine" - per definition has to replicate its predecessor.

    While lowlevel comparisions have their value, I was thinking of directly comparing two "as similar as possible" GUI applications. My whole aim in this discussion is to point out that the QML engine is burning up your precious CPU cycles. It is interesting to see that you outright dismiss an overall compare between UI technologies. Do you fear that this would directly shine a light on your claims?
    There is Qt for MCU which is using a QML dialect to directly create structs. So no heap allocations for QObject anymore. They should have gone that route from the beginning. Slint is using actually the same approach(it is done actually be the same people who started Qt for MCU).

    Leave a comment:


  • lowflyer
    replied
    Dear anda_skoa ,

    Your personal iron-clad definition of what a web engine is makes it impossible to get the slightest point through to you. It makes it *very* difficult to even communicate with you. It is not helpful to assume the other extreme if you disagree.

    You contradict yourself:
    Originally posted by anda_skoa View Post
    Originally the engine was built around WebKit's V8 engine but that got replaced by a custom implementation called V4.
    You say QML got WebKit's V8? ... A web engine? -- This is *exactly* my initial point.
    The replacement V4 - you even call it "engine" - per definition has to replicate its predecessor.

    While lowlevel comparisions have their value, I was thinking of directly comparing two "as similar as possible" GUI applications. My whole aim in this discussion is to point out that the QML engine is burning up your precious CPU cycles. It is interesting to see that you outright dismiss an overall compare between UI technologies. Do you fear that this would directly shine a light on your claims?

    If you're not willing to soften up in your argumentation I might loose interest in continuing this discussion.

    Leave a comment:


  • anda_skoa
    replied
    Originally posted by lowflyer View Post
    You only accept the term "web engine" for your specific definition of what a web engine is, something like QtWebView
    Exactly.
    There is neither HTML nor CSS involved in QML.

    By your definition any UI framework is a web engine because they work on trees of objects.

    Originally posted by lowflyer View Post
    Even if it does *exactly* the same thing
    But it does not the exactly the same thing.
    It is incapable of processing content intended for a web engine.

    Originally posted by lowflyer View Post
    I see you bending arguments. When I talk about `WebSocket` and `web stack` you say it has nothing to do with a web enigne
    How is that bending the argument.
    The Qt WebSocket implementation simply doesn't need access to a web engine.

    The technology is called Web Sockets because it originated from the need of web engine based apps to have a data stream connection to their server.
    Even in a browser it is a non-UI object with API accessible for the web engine, it doesn't need the web engine itself.
    The server side does not need one either.

    Qt's web socket is available as a C++ class without any dependency on QML or any web engine.
    Its QML type is just that C++ type registered with QML.

    Originally posted by lowflyer View Post
    further up in the discussion state something like "It cannot be a web engine because it lacks a web stack".
    Exactly.

    Originally posted by lowflyer View Post
    And here, you use "Qt for MCU", a non-default case as an argument - while you (further up) claim to care only about default cases.
    I am sorry, but not having scripting capability is the default for Qt for MCU.
    Not an optional choice like forcing software rendering into Qt Scene Graph or Qt RHI.

    Originally posted by lowflyer View Post
    You claim to have good experience with QtQuick - I don't deny that.
    Same for you but you seem not to be up to date.
    Originally the engine was built around WebKit's V8 engine but that got replaced by a custom implementation called V4.
    They put a lot of effort into minimizing transitions between the C++ and script domains.

    To the point that a lot of binding expressions can be handled directly in C++.

    Mostly to work around restrictive platforms such as iOS which don't allow just-in-time compiling, but also giving a nice peformance improvement on others.
    This can both be done either at runtime or compile time. In case of Qt for MCU it is always at compile time.

    Originally posted by lowflyer View Post
    Question (please answer honestly): Did you ever make a one-to-one performance comparision between a QtQuick and a "classical" Qt Widgets application?
    If I wanted to get numbers on the overhead for the QML engine I would not compare two different UI technologies, but the same objects.
    For example non-UI classes or using Qt Widgets from QML and C++.

    Let's say we had two classes
    Code:
    class Source : public QObject
    {
        Q_OBJECT
        Q_PROPERTY(int value READ value NOTIFY valueChanged)
    
    public:
        Source() {
            QTimer *timer = new QTimer(this);
            timer->callOnTimeout(this, [this](){
                emit valueChanged(0);
            });
            timer->start(10);
        }
    
        int value() const { return 0; }
    
    Q_SIGNALS:
        void valueChanged(int value);
    };
    
    class Sink : public QObject
    {
        Q_OBJECT
        Q_PROPERTY(int value READ value WRITE setValue NOTIFY valueChanged)
    
    public:
        void setValue(int newValue) { emit valueChanged(newValue); }
        int value() const { return 0; }
    
    Q_SIGNALS:
        void valueChanged(int value);
    };
    In C++ we would connect them like this
    Code:
    auto source = new Source;
    auto sink = new Sink;
    connect(source, &Source::valueChanged, sink, &Sink::setValue);
    In QML we would be using a property binding
    Code:
    Source {
        id: source
    }
    Sink {
        value: source.value
    }​​​​​​​
    Then we could measure, e.g. 1 million time cycles and see how much the binding overhead was compared to the C++ connect
    ​​​​​​​

    Leave a comment:

Working...
X