02.06.2021 00:47, Ola Fosheim Grøstad пишет:
> Note: Many simple GUI toolkits are horribly inefficient as they let each object render themselves.  An efficient GUI engine will have to replicate some of the browser complexity...

I tried retained and immediate GUI, both fail (imho) for my use case - large data set of 1M+ heterogeneous items. GTK and Qt are very complicated in case of TreeView widgets in contrast to dear imgui or nuklear. In retained GUI (GTK and Qt) you need to prepare your data, create some intermediate data, probably copy data. TreeView in immediate GUI (imgui, nuklear) is pretty trivial and intuitive - you just use your data w/o anything else but it draws all items always so immediate GUI works nice if you have small data set. nuklear lets you use large data set but only if items have the same height. But because an item of TreeView can be collapsed or not its height changes and you need to calculate height for each items - you can do it yourself but available implementations of immediate GUI aren't capable to use that info so you need to modify immediate GUI core system and that is very complicated job in contrast to retained GUI where adding new widget is much easier.

I was forced to invent my own wheel some where in-between retained and immediate GUI. Later I got know that it worked like browsers did (of course in general). I think that browser-like GUI is the future. Just current browsers are very over-engineered.

My impression is that immediate and retained GUI belong to different domains and are not interchangeable. Browser-like GUI is superset of both retained and immediate GUI. Just it should be implemented properly.

On Wednesday, 2 June 2021 at 09:37:10 UTC, drug wrote:
> 02.06.2021 00:47, Ola Fosheim Grøstad пишет:
> I tried retained and immediate GUI, both fail (imho) for my use case - large data set of 1M+ heterogeneous items.

Depends on the data, I guess, if they are all visible at once then you basically have to very carefully write your own GPU render stage for that view and carefully cache things that does not move by rendering them to buffers (in GPU memory).

> I was forced to invent my own wheel some where in-between retained and immediate GUI. Later I got know that it worked like browsers did (of course in general). I think that browser-like GUI is the future. Just current browsers are very over-engineered.

They have some inefficiencies in how the DOM is being manipulated (like setting numeric styles as strings, but there is a fix coming for this, maybe it is available already?)

But if you deal with large number of items you basically can write your own view and dynamically create elements as the user scrolls. You do need to estimate the height though.

You can have a web-worker handling the dataset and basically stream it to the main thread that does the GUI. There is a delay though, so it takes some tweaking.

02.06.2021 12:50, Ola Fosheim Grøstad пишет:
> Depends on the data, I guess, if they are all visible at once then you basically have to very carefully write your own GPU render stage for that view and carefully cache things that does not move by rendering them to buffers (in GPU memory).

Usually 1 million of items aren't visible at once. Also there is opinion that total redrawing can be more efficient than caching because of making a decision what to cache and what not can be very complex.

> But if you deal with large number of items you basically can write your own view and dynamically create elements as the user scrolls. You do need to estimate the height though.

To estimate the height you need to have height of every elements, you can't dynamically create elements in that case. I create some wrapper over data set that stores height of elements. It's much cheaper and faster than creating a widget per item - that is a real advantage over retained gui. And user has access to that info - that is advantage over immediate gui. But yes, there are tasks that can/should be performed by dynamically created elements.

On Wednesday, 2 June 2021 at 10:17:52 UTC, drug wrote:
> Usually 1 million of items aren't visible at once. Also there is opinion that total redrawing can be more efficient than caching because of making a decision what to cache and what not can be very complex.

Depends on the application.

My view on the GPU has changed a bit as some applications may use the GPU for computing application data, also pushing the GPU too hard will make it hot and fans  start running (making users wonder what the app is doing).

Say, if I used an accounting program and it caused the fan to spin, then I would be annoyed. :-D

> To estimate the height you need to have height of every elements, you can't dynamically create elements in that case. I create some wrapper over data set that stores height of elements. It's much cheaper and faster than creating a widget per item - that is a real advantage over retained gui. And user has access to that info - that is advantage over immediate gui. But yes, there are tasks that can/should be performed by dynamically created elements.

Varying heights can be tricky, so just computing the heights in a wrapper seems reasonable.

Another approach is to use an estimate that is updated as you bring in more items, but that is real work (for the programmer).