Unsolved I did a test QWidget 5% CPU Max and QML up to 50%
-
@archqt For the value there are hight because of Kde5 (plasma). On lxqt i have 5% for QML and less than 1% (max 1%) for QWidgets. So it is a bit better but QML is far slower.
I don't have any javascript on it so why is there a so big difference from QML to QWidgets ? -
TableView from Qt Quick Controls 1.x is unfortunately a very bad example. Please do not use it for measuring the performance of Qt Quick or QML. A ListView with a delegate that contains multiple columns is a million times faster.
-
Hi,
ok i will look at it.
Thanks -
Is the TableView from QtQuick Controls 2 better?
-
@AlaNan said:
Is the TableView from QtQuick Controls 2 better?
There is no TableView in Qt Quick Controls 2. We surely would like to offer a fast TableView in the future, but it’s not a small task to rewrite that beast so that it performs well. ;) We’ll probably take quite different approach, something much closer to ListView and GridView in Qt Quick core. Any progress on this can be monitored via QTBUG-51710.
-
Thank you very much for the information. I sure hope you will come up with something soon. I strongly rely on table views in my applications. Seems that the decision to switch to QML was premature ... I expected it to be further developed than it currently is, but that's probably my fault :-/
-
@AlaNan Which particular features of TableView do you need? Qt Quick Controls 2 provides a bunch of styled item delegate types. It is straight-forward to build a multi column view by using ListView from Qt Quick, and using a Row as delegate. It's a whole different story if you're after draggable or resizable columns, or other classic desktop behavior, of course.
-
@jpnurmi That's interesting, didn't think of that.
Sadly it's exactly the classical desktop behavior I'm after. I'm currently struggling with resizing columns on doubleclicking on the column delimiters as I described here.
I had the (probably naive) idea that QML/Qt Quick would give me the classical desktop environment like QWidget did and additionally give me the opprtunity to move to mobile devices easily if desired. Moreover I really like the declarative approach to create the GUI part of an application. Now switching back to QWidget seems too costly so I have to get along with what QML currently provides. Please note that I'm not blaming anyone but myself for this situation which I'm in due to my misjudgement of what QML/QT Quick does provide at the moment. I really appreciate what the Qt developers have achieved so far and I'm positive that QML will become a great framework also for desktop development eventually! -
@jpnurmi btw, is there any plans to continue work on this? I have an application with several TableView' s handling thousands of row and its so slow, that I even started to do my own simplified TableView implementation w/o those huge amount of costly bindings. But may be I just doing work which someone already did
-
@vladstelmahovsky made a prototype in QML/JS. Starting to move to C++
-
@jpnurmi btw, is there any plans to continue work on this?
Yes, it's on the TODO-list among many other things. :) Unfortunately we only have some rough prototypes so far. When a new TableView will be introduced, there certainly won't be any JS involved. The goal is to make it as fast as ListView and GridView, and support all the same item view transitions and so on. In other words, the implementation is likely to be based on the same internal QQuickItemView class, but just provide a table layout for the items. The cumbersome part is to try to somehow support those classic desktop use cases that are conveniently baked into the TableView type in Qt Quick Controls 1.