[Interest] Antwort: Re: QML Loader Performance

Bo Thorsen bo at vikingsoft.eu
Wed Mar 9 11:32:15 CET 2016 

Den 09-03-2016 kl. 08:30 skrev Ingo Schiller:
> Hi Bo, Hi everyone
>
> thanks for your reply and the thoughts you have spent on my problem.
>
> You are right, using these cascading loader elements is a fundamental
> structure of the program which will not be easy to change. The point is
> that everything is user editable. The user can decide which blocks
> should be displayed and which widgets (there is the bad word again ;-) )
>   are displayed. Almost everything is editable, positions, sizes,
> parameters... And widgets are attached to theses blocks and relative to
> them ,meaning they can be dragged around with them and change size with
> them, etc.. Thats also the reason why I can not just use ony hierarchy
> of loaders, that would not allow to change the content of the blocks.

Which is also why I'm advocating the model based approach because that 
one attacks the problem from a completely different angle and will most 
likely solve your issues.

> I don't think I understood your proposed approach:
>
> "Another option would be to attempt this with C++ instead of doing
> loaders. I mean instantiating every item inside in C++ code instead of
> doing it in QML/JS code. This makes the code a lot less friendly to
> modify, but it seems you are desperate enough to start pulling out
> solutions that hurts in other ways just to get more speed."
>
> How can I generate visual QML elements in C++? These are mostly elements
> drawn in QML so how could I achieve this? (Some of them are drawn in c++
> and exportet to QML)

QQmlComponent component(yourView.engine(),
   QUrl::fromLocalFile("MyItem.qml"));

for (...)
   QObject *object = component.create();

Now set the parent to the parent in the qml view (which you can get with 
a Q_INVOKABLE method.

This is basically what a loader does. But with a loader, you create the 
component every time. Here you can reuse the component to create all the 
widgets.

> Your last point, to do a redesign on models instead, could be possible I
> think, although it would require a lot of changes to give it a try. I
> could make everything a widget and establish the hierarchy in some other
> way so that widgets can still be relative to blocks in terms of
> position. Although I also tried only having one block on a page and
> putting  all widgets in there which did not improve loading speed.

Yes, it will be a lot of work, and the dynamic creation would be less to 
try first. But this is the real solution to your problem and speedwise 
it will be many times faster than the loaders.

Bo.

> Von: Bo Thorsen <bo at vikingsoft.eu>
> An: interest at qt-project.org,
> Datum: 08.03.2016 15:37
> Betreff: Re: [Interest] QML Loader Performance
> Gesendet von: "Interest"
> <interest-bounces+ingo_schiller=raykiel.com at qt-project.org>
> ------------------------------------------------------------------------
>
>
>
> Hi Ingo,
>
> Den 07-03-2016 kl. 08:27 skrev Ingo Schiller:
>  > I have a serious performance problem in my application which uses QML
>  > for the UI and several C++ datamodels. The application consists of
>  > several "pages", which is a set of ui elements and covers the whole
>  > screen. These pages can be loaded on request. Loading such a page is
>  > done by a QML Loader component. The loaded page itself loads other
>  > elements, so called "blocks" which group several ui elements. These
>  > "blocks" also contain a loader element which loads so called "widgets",
>  > UI qml elements used to display information. After loading a block or
>  > widget JS functions are used to set the properties (15 - 30) of the ui
>  > elements such as position, z-layer, data to display, etc.
>  >
>  > Load Page -> load block 1 -> load widget 1
>  >     -> load widget 2
>  >     -> load widget 3
>  >                ...
>  >     -> load widget n
>  >             -> load block 2 -> load widget 1
>  >     -> load widget 2
>  >     -> load widget 3
>  >                ...
>  >     -> load widget n
>  >            ...
>  >             -> load block n  -> load widget x
>  >
>  > The problem is, that loading sich a "page" is far too slow, On a really
>  > good developer PC and as a release build it takes 150ms. On a weaker
>  > hardware it takes several seconds which is not acceptable. The time
>  > required to load a "page" is linear with the amount of "widgets" on that
>  > "page", no matter what widgets are on that page. I have very simple
>  > widgets which have only a label to display, up to grafical widgets with
>  > transparency and animations, but that does not seam to influence the
>  > loading procedure.
>  >
>  > I already tried several things  to speed it up:
>  > - Use qt quick compiler
>  > - Strip down loaded elements to have fewer properties
>  > - Construct all elements on startup and only set them (in-)visible on
>  > request
>  > - Omit z-layering
>  >
>  > Profiling the loading procedure shows that compiling the qml elements
>  > and painting are not the issues.
>  >
>  > Can anyone advise what I could do else? Or is that loader component so
>  > terribly slow? Any help is highly appreciated!
>
> What you're doing here seems really difficult to speed up. I guess the
> problem is the multiple layers of loaders you have.
>
> But I guess that's a pretty fundamental design for you application, and
> not one you're about to change.
>
> If you could create a set of pages based on the blocks that can go in
> them, you could have a single loader object instead of the n * m + 1
> loaders you're doing right now.
>
> Another option would be to attempt this with C++ instead of doing
> loaders. I mean instantiating every item inside in C++ code instead of
> doing it in QML/JS code. This makes the code a lot less friendly to
> modify, but it seems you are desperate enough to start pulling out
> solutions that hurts in other ways just to get more speed.
>
> If you can cut down on the initialization for each page, block or
> widget, that would obviously help a lot. You mention that JS code is run
> after each add, which sounds like a place where you might have some
> possibilities.
>
> Fewer bindings might also be a possibility.
>
> Have you considered a total redesign based on models instead? It sounds
> like a page is really just a list of widgets - which is a bad word in
> QML land :) - so perhaps you would be much better off with a standard
> list model, a list view where what you have as a widget now is a
> delegate for a row in the model. That would definitely be much much
> faster than what you're doing right now.
>
> Those are just the ideas I have off the top of my head. I hope it helps.
>
> Bo Thorsen,
> Director, Viking Software.
>
> --
> Viking Software
> Qt and C++ developers for hire
> http://www.vikingsoft.eu <http://www.vikingsoft.eu/>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
>
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>


Bo Thorsen,
Director, Viking Software.

-- 
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu

More information about the Interest mailing list