undefined | Better HN

0 pointsamelius5y ago0 comments

Perhaps I should give a different example: a listbox filled with 1 million items, with a scrollbar.

If the public API requires you to give a new paint command on every frame (everytime the scrollbar is dragged), then regardless of whether the underlying rendering engine performs each of these paint commands, you still have to run through every item of the list (and so does the diff'ing code), making this a O(N) operation on every frame.

0 comments

flohofwoe5y ago

From what I've seen (in Dear ImGui), this is solved by not giving the 1 million items to the API, instead you can query what range of the list is currently visible, and only describe those to the API (in Dear ImGui this is called a ListClipper).

But I guess different UI frameworks have different solution for this. Creating and updating a 1 million item list wouldn't be a cheap operation in a traditional UI system either.

ameliusOP5y ago

Ok. Yes my point is not that you can't find efficient ways around the limitations, but my fear is that you end up with a system that is less ergonomic in the end.

nikki935y ago

These aren't just workarounds. It's often the natural immediate mode api. A lot of immediate mode "scroll view" systems just have a child lambda passed with an index for which element to render, and it only calls the lambda for what's actually in view. (eg: the Gio API in Go)

Concrete examples of code that is not immediate mode api, vs. code that is immediate mode api, both implementing the same thing, can help discuss / reflect on that fear. IME immediate mode is great for mapping tree-ish data to tree-ish UI; when things have a lot of nontree linkages or reordering (eg. when you do drag and drop) it gets trickier. React's JSX / createElement API also feels somewhat immediate mode, tbh; the updates are just scheduled to fire on state changes.

1 more reply

jcelerier5y ago

> Creating and updating a 1 million item list wouldn't be a cheap operation in a traditional UI system either.

IDK, works pretty well with Qt's item model system

coldtea5y ago

That's becuase it too (in all probability) doesn't render 1 million offscreen elements to show the handful (100? 1000?) on screen elements.

So it does it just like an immediate mode GUI does it, and only renders what it must.

Not sure about QT specifically, but all other non-immediate mode GUIs I know use the same trick, and immediate mode GUIs like React also use it.

wdfx5y ago

It's not difficult to implement a 'virtual' list which renders only the items which are visible. It's a little trickier if your list items are not all the same height, but not impossible.

j / k navigate · click thread line to collapse