4 ms·

QML isn't slower than Qt QWidgets, in the end of the day Qt Quick components are simply C++ objects, you can look at the source code[1]. [1] https://github.com

QML isn't slower than Qt QWidgets, in the end of the day Qt Quick components are simply C++ objects, you can look at the source code[1]. [1] https://github.com/qt/qtdeclarative https://github.com/qt/qtdeclarative

noodletheworld 10mo ago
Hum… QtQuick uses a different runtime which is (afaik) faster and targets modern graphics backends (eg. Vulcan) in a way widgets does not. It also uses an a javascript scripting engine. Saying “they’re both c++” is seems kind of misleading and meaningless right? It’s probably more accurate to say QML is actively being worked on and receiving performance enhancements and updates and widgets is not, and has not for some time. So yes, it’s actually pretty unlikely that QML would be slower (depending on what you do with your scripts) but it’s probably not as clear cut as you are suggesting. QML apps that heavily implement core logic in javascript would be slow as balls.
- rubymamis 10mo ago
  > Saying “they’re both c++” is seems kind of misleading and meaningless right? Not really, if you avoid writing Javascript code in your QML components, than most of your executable will end up being compiled C++ code. If you do write Javascript code in your QML components, than it *could also* be compiled to C++ code using the QML script compiler[1[2]. > QML apps that heavily implement core logic in javascript would be slow as balls. The entire point is to separate logic and view where logic is written in C++ and QML simply represents the view (which almost end up being built upon simple primitives that *are* C++ objects). So if you keep this separation you get amazing performance with great simplicity and velocity. [1] https://doc.qt.io/qt-6/qtqml-qtquick-compiler-tech.html https://doc.qt.io/qt-6/qtqml-qtquick-compiler-tech.html [2] https://doc.qt.io/qt-6/qtqml-qml-script-compiler.html https://doc.qt.io/qt-6/qtqml-qml-script-compiler.html
  - noodletheworld 10mo ago
    > than it could also be compiled to C++ People who are going to use it should read the documentation. “It depends” and “it’s still slow” are the fairest comments I can make about this.
    - rubymamis 10mo ago
      I already showed in my benchmarks that my block editor is faster than all block editors on the market - even more than those that uses native frameworks. And there are ten of thousand of lines of QML code (and round the same of C++ as well). You can't claim something is slow without showing empiric data. I showed mine when I claimed programming Qt C++ and QML together is fast. If you claim otherwise, you need to support it with data.
      - asyncze 10mo ago
        [dead]
    - ahartmetz 10mo ago
      If you ever run into trouble with execution of JS slowing down your Qt/QML application, you are using way too much JS. The most common performance issues in decently written applications are rendering of invisible items aka overdraw (especially on very weak embedded SoC GPUs) and slow startup time. There is tooling to find these and ways to fix or improve them.
      - rubymamis 10mo ago
        Hi there! > The most common performance issues in decently written applications are rendering of invisible items aka overdraw That's indeed what I found as well! Especially, these hidden items consume a lot of unnecessary RAM. What tools do you know for Qt/QML that can help with this issue?
        ahartmetz 9mo ago
        QSG_VISUALIZE=overdraw, and the other options described here help with rendering performance well: https://doc.qt.io/qt-6/qtquick-visualcanvas-scenegraph-renderer.html https://doc.qt.io/qt-6/qtquick-visualcanvas-scenegraph-rende... For another perspective and more details, RenderDoc (or another frame debugger if you have one) is a nice tool as well. Also don't use Rectangle { color: "transparent" }, use Item {}. An Item has geometry, but doesn't render anything. A transparent Rectangle probably also doesn't render, but it's still (at least slightly) more resource-intensive and makes you look like you don't know what you're doing. Use Loader, StackView and visible liberally to disable stuff that isn't currently relevant. If unloading causes trouble with lost state, you may be carrying too much state on the QML side.

noodletheworld 10mo ago

Hum… QtQuick uses a different runtime which is (afaik) faster and targets modern graphics backends (eg. Vulcan) in a way widgets does not. It also uses an a javascript scripting engine. Saying “they’re both c++” is seems kind of misleading and meaningless right? It’s probably more accurate to say QML is actively being worked on and receiving performance enhancements and updates and widgets is not, and has not for some time. So yes, it’s actually pretty unlikely that QML would be slower (depending on what you do with your scripts) but it’s probably not as clear cut as you are suggesting. QML apps that heavily implement core logic in javascript would be slow as balls.

rubymamis 10mo ago
> Saying “they’re both c++” is seems kind of misleading and meaningless right? Not really, if you avoid writing Javascript code in your QML components, than most of your executable will end up being compiled C++ code. If you do write Javascript code in your QML components, than it *could also* be compiled to C++ code using the QML script compiler[1[2]. > QML apps that heavily implement core logic in javascript would be slow as balls. The entire point is to separate logic and view where logic is written in C++ and QML simply represents the view (which almost end up being built upon simple primitives that *are* C++ objects). So if you keep this separation you get amazing performance with great simplicity and velocity. [1] https://doc.qt.io/qt-6/qtqml-qtquick-compiler-tech.html https://doc.qt.io/qt-6/qtqml-qtquick-compiler-tech.html [2] https://doc.qt.io/qt-6/qtqml-qml-script-compiler.html https://doc.qt.io/qt-6/qtqml-qml-script-compiler.html
- noodletheworld 10mo ago
  > than it could also be compiled to C++ People who are going to use it should read the documentation. “It depends” and “it’s still slow” are the fairest comments I can make about this.
  - rubymamis 10mo ago
    I already showed in my benchmarks that my block editor is faster than all block editors on the market - even more than those that uses native frameworks. And there are ten of thousand of lines of QML code (and round the same of C++ as well). You can't claim something is slow without showing empiric data. I showed mine when I claimed programming Qt C++ and QML together is fast. If you claim otherwise, you need to support it with data.
    - asyncze 10mo ago
      [dead]
  - ahartmetz 10mo ago
    If you ever run into trouble with execution of JS slowing down your Qt/QML application, you are using way too much JS. The most common performance issues in decently written applications are rendering of invisible items aka overdraw (especially on very weak embedded SoC GPUs) and slow startup time. There is tooling to find these and ways to fix or improve them.
    - rubymamis 10mo ago
      Hi there! > The most common performance issues in decently written applications are rendering of invisible items aka overdraw That's indeed what I found as well! Especially, these hidden items consume a lot of unnecessary RAM. What tools do you know for Qt/QML that can help with this issue?
      - ahartmetz 9mo ago
        QSG_VISUALIZE=overdraw, and the other options described here help with rendering performance well: https://doc.qt.io/qt-6/qtquick-visualcanvas-scenegraph-renderer.html https://doc.qt.io/qt-6/qtquick-visualcanvas-scenegraph-rende... For another perspective and more details, RenderDoc (or another frame debugger if you have one) is a nice tool as well. Also don't use Rectangle { color: "transparent" }, use Item {}. An Item has geometry, but doesn't render anything. A transparent Rectangle probably also doesn't render, but it's still (at least slightly) more resource-intensive and makes you look like you don't know what you're doing. Use Loader, StackView and visible liberally to disable stuff that isn't currently relevant. If unloading causes trouble with lost state, you may be carrying too much state on the QML side.