Very large scrollable areas (~millions of lines) cannot be scrolled

[mahlemiut]

When making a very large child area in a window, there is no vertical scrollbar. If you force the vertical scrollbar to appear, then it does appear, but isn't scrollable, as if the area was smaller than what is visible.

Currently, I have a memory viewer/editor, and it renders only the visible text, based on the vertical scrollbar position. The size of the scrollable area is set first via SetCursorPosY(). Rendering is via adding to the ImDrawList of the area.
It works fine, except when I need to view a 32-bit memory space. Just to get an idea of the size, using the default font, 16 bytes displayed per line by default, about 268,435,456 lines * 13 pixels per line.

From a quick look into imgui.cpp, I see that when the cursor position is set, it is cast to (float)(int), and that seem to truncate the result, effectively making the size negative. As a test, I removed the (int) cast at line 3937 of imgui.cpp, so that it's just cast to (float), and that makes the scrollbar work, although it will glitch when scrolling down a certain amount (probably from other (float)(int) casts?)

[ocornut]

Hello,
For that amount of lines wouldn't a scrollbar be totally useless anyway?
Prefer using a "Goto address" box and perhaps some combo for important range?

By the way you can use normal ImGui widgets and still seek and display only the visible area, which is what https://github.com/ocornut/imgui/wiki/memory_editor_example is doing.

[mahlemiut]

It does have a text box to set the current address, which actually just adjusts the scrollbar (which is difficult when there isn't one ;))

Will look at the example, and find some workaround.

[ocornut]

Once scrolling is applied the cursor position are always stored in screen-space, so the "visible area" will always be small numbers and seeking/displaying there will be safe.
You are right that effectively those cast may affect the scroll value but with a 2+ billions pixels range it is probably hard to get it. In theory widgets can be layed out from the highest point to the lowest points and layout calculation won't be correct at those extremes. A (probably unacceptable) solution would be to switch all layout/cursor data to double, or perhaps (more acceptable) see if it could work out with integers. Not a trivial change however.

The easier way if you really want a scrollbar and scrolling that spans that amount of data is to just emulate scrolling yourself (by setting the cursor position) and create a custom scrollbar, which would made sense if you are going to want it to be useful. A traditional scrollbar will just suck at being useful for 200 millions lines?

[emoon]

I guess this is similar to this one #150 ?

I started to make an example of it here but it really doesn't work that good (yet)

https://github.com/emoon/imgui/blob/bec45a458ed2c16d787128e0f656635420999275/imgui_demo.cpp?ts=4#L1980

[brett19]

Hey @ocornut,
I also just ran into this issue myself. I was working modifying your Memory View for a 32-bit address space (emulator related) and found myself with no scroll bar. The argument that a scroll bar for this amount of data would be useless is understandable, however the problem is that it is typically expected that a scrollbar would exist for a list-type view and handling scrolling manually is a lot more work than seems should be necessary for a use case such as this.
Cheers, Brett

[ocornut]

is that it is typically expected that a scrollbar would exist for a list-type view

@brett19 I don't understand this paragraph. What are you expecting to happen? My point is that a scrollbar just wouldn't be any useful if you are spanning 200 millions lines, so fixing the issue wouldn't help here. How are you expecting to use a scrollbar in a meaningful manner with that amount of data?

[brett19]

Hey @ocornut,
I sometimes will use the scrollbar to get to the right region, and then perform some more precise adjustments with my scroll wheel to get to the area I want to be in. I do agree it is a slightly absurd way to go about it. After writing my above post, I did end up adjusting the view to map out only one region of memory at atime.
Cheers, Brett

[ocornut]

Closing this at it looks like original posters don't need it.
However I still want to add a "virtual scrolling" example probably based on code Daniel linked above;
https://github.com/emoon/imgui/blob/bec45a458ed2c16d787128e0f656635420999275/imgui_demo.cpp?ts=4#L1980

And added that as a separate task in my list.

[emoon]

@ocornut Worth to mention is that my code isn't really working that good so it would need to be improved before going into imgui_demo

[trss]

By the way you can use normal ImGui widgets and still seek and display only the visible area, which is what https://github.com/ocornut/imgui/wiki/memory_editor_example is doing.

Broken link. I suppose https://github.com/ocornut/imgui_club is the current link. It's the first one listed under https://github.com/ocornut/imgui/wiki/Useful-Widgets#miscellaneous.

Edit: https://github.com/ocornut/imgui_club/tree/master/imgui_memory_editor seems more accurate.