Hi,
When I use the todo example with a 10 MB json (attached), and I filtering the tasks, it uses 1.4 gigabytes ram even if only the one completed task is listed.
So what I would like to achieve (without limiting the displayable results) is low memory usage when only a few element is listed.
And in general I'm curios what is using the memory in the background, and why is it using more and more when I'm switching between active and completed tasks.
(I would like to create my first GUI app in rust, and I'm not very experienced, so sorry if its a stupid question)

Not a stupid question!
The todos example is quite naive (like many parts of the library!). It uses a Scrollable, which currently does not cull any primitives when drawing (see #584). This effectively means that it will generate and upload all the graphics primitives of your 60k+ tasks.
Furthermore, our current text pipeline will increase the size of its instance buffer to draw everything at once. There is currently no logic in place to decrease the size of the buffer after an increase.
There are plans to build a widget to support rendering a potentially infinite list of values (a Menu is already able to do that). This widget will build its children lazily and either cache layout smartly or have specific layout constraints. There is a discussion about it in our Zulip server.
thank you very much for the detailed answer
Most helpful comment
Not a stupid question!
The
todosexample is quite naive (like many parts of the library!). It uses aScrollable, which currently does not cull any primitives when drawing (see #584). This effectively means that it will generate and upload all the graphics primitives of your 60k+ tasks.Furthermore, our current text pipeline will increase the size of its instance buffer to draw everything at once. There is currently no logic in place to decrease the size of the buffer after an increase.
There are plans to build a widget to support rendering a potentially infinite list of values (a
Menuis already able to do that). This widget will build its children lazily and either cache layout smartly or have specific layout constraints. There is a discussion about it in our Zulip server.