Good afternoon. The task was to develop an interface for the device, in which a huge number of parameters. For each parameter, a corresponding input field is created. At the entrance there is a tree of groups into which these parameters are distributed. This tree is transferred to QML and on its basis a tree-like interface with tabs is created dynamically, in which input fields are located. Initially, all tabs are closed and the user does not have the opportunity to open them all.

Each group of parameters requires approximately, AVG, 2 MB of memory (this was found out during the debugging of the application with a parallel view of the amount of RAM consumed in the task manager).

Based on one parameter tree, a 200 MB interface window is generated. The number of parameters varies around a thousand. Those. for each parameter dynamically (SINGLE) is created (label + textEdit + checkBox). The program should load 10 of these windows, which means it will open about 2 GB.

The problem is that the program can withstand no more than two or three such trees. If you load more, then SIGSEGV will definitely crash or the program will freeze when you try to open the generated window. The fact that the program quietly maintains 10-15 trees is less, where the number of parameters does not exceed hundreds.

Immediately take on faith: There are no memory leaks, since all objects are created dynamically only once.

The essence of the question: Is QML designed for such loads, when, at a time, it loads over a thousand graphic objects? Perhaps you had experience in QML with a large number of objects, share, if not difficult.

  • one
    I don’t know about calculated / not calculated, but maybe it’s not necessary to create controls for each parameter? And just when switching to the next tab, use the existing ones, changing their signatures? For example, make a panel with a tree (hierarchy) (as in the file system), on which you can move, and when selecting a particular element from the hierarchy, display only those parameters that can be entered in this element. It is not necessary to tightly bind the control / input with each parameter. - vegorov
  • one
    "200 MB interface window is generated" what kind of interface is 200 meters? O_o - Bearded Beaver
  • 2
    QML and graphic frameworks are generally not designed for such workloads. QML in terms of efficiency does not bother at all. It is understood that at one time only the objects directly displayed on the screen at the moment will be processed. Don't make thousands of widgets. Make them a couple of dozen or how many will fit on the screen and update the data in them when scrolling and transitions. - VTT
  • @BeardedBeaver, an interface in which there are 1000 parameters, each of which relies on 3 graphical widgets. + other qml objects not visible on the screen. By the number of fields in each object in more or less converges. - Prost971
  • I do not say that my approach is correct. Yes, and I myself adequately understand that 200 MB is too much. So looking for new solutions. - Prost971

0