Hacker News Reader

Comment by amelius | Hacker News Reader

Say I have a very long listbox containing thousands of items, and each item has a height that may be different (e.g. a list of font families where each line may have a slightly different line height).

How would IMGUI perform the drawing, given the scrollbar is at (say) 20%?

View on HN

I'm not sure I've ever used any library that goes to any particular effort to support this sort of thing. The standard assumption for listboxes is that every row has the same height. So you'd probably handle it the same way you would with any other system: accept that there'll be some effort involved, and get the library to do the remainder for you. So, probably, something like let the library know the total height of the contents, have it look after the viewport height and scroll bar position for you, and then draw the viewport contents as required.

Your browser goes through extraordinary lengths to support this sort of thing.

I guess I just got old at some point. I simply don't think of web browsers as relevant when it comes to programming.

> and each item has a height that may be different

This criterion means you'd have to roll your own solution. Otherwise, ImGuiListClipper exists for exactly this kind of thing.

https://github.com/ocornut/imgui/blob/864a2bf6b824f9c1329d84...

I'm not a fan of IMGUI, but there is nothing about it that prevents caching data (in fact AFAIK most IMGUI libraries do cache data), so it'd be done pretty much the same way as in a regular GUI library: by caching the (unscrolled) item rects, updating the rect cache whenever the listbox size changes, caching the visible (after scrolling) items and updating the cache whenever the listbox size or scroll position change. Might have forgotten some other case, but the idea is the same.

But caching means that you're storing information about the items, which brings you closer to RMGUI.

I feel like I must be missing something here. Why not store the ID of the top-most visible list item, and just render the next n until you run out of box height? Surely you're not trying to draw thousands of items that aren't even visible on screen?

Reply on news.ycombinator.com