Version/Branch of Dear ImGui:
Version: Dear ImGui 1.80 WIP (17905), merged with tables branch
Branch: docking merged with tables
Printout from imgui_demo at end of this text.

Back-ends: imgui_impl_glfw.cpp + imgui_impl_glfw.cpp
Compiler: gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
Operating System: Linux stalin 4.4.0-127-generic #153-Ubuntu SMP Sat May 19 10:58:46 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

My Issue/Question:

Question: What would be the best way to handle large tables?

General: ImGui table architecture is good for showing "spreadsheet tables. Customizable column headers, frozen columns, and row headers make it flexible for many uses. The question is more about how to use it efficiently when the table is big.

I was testing Dear ImGui to display large data tables: I modified the code a bit to avoid the 64 column limit.

• I tested with a table of 400 columns and 20000 rows. I changed the appropriate type of ImS8->ImS16, 64 bitmasks to arrays, and appropriate defines for the test. This is just simple mechanical change, changes marked with string "PEKKA" in https://github.com/iocafe/bluetree/blob/master/egui/code/imgui/imgui_internal.h and https://github.com/iocafe/bluetree/blob/master/egui/code/imgui/imgui_widgets.cpp.
• It works, but it makes the UI sluggish. Looping through a large number of rows x columns at screen refresh, not the best way.
• Overall I liked table API and examples. Clean and understandable.

So I was looking for a better way to do this:

• Determining cell size by content may not be ideal for large tables, maybe it would be ok if it is done only when table content changes. Using a fixed or predetermined row height and a predetermined column is what I can think of.
• Skipping the invisible rows and columns would make it fast. Displayed part of the table is a small window into a large table. The application should somehow figure out (information from the table) ranges of visible rows and columns and call ImGui only for those cells.
• Alternatively, I could think that I always present the only subtable of a large table to ImGui. This is a bit of cake on top of a cake solution and leaves issues with scrolling, moving input focus, etc. open.

Then I am unsure if displaying large tables is needed often enough to justify handling it. If it is not, that is also good information, then I can make a modified version of ImGui Table what is optimized for my case. Modifications for that are relatively small. Just idea of me writing own GUI components is a bad one, they will easily be incompatible with the future version of ImGui, and I know that the day will come when that would bite me back.

Screenshots/Video

Best regards,
Pekka

ps. I hope I post to the right place this time.

Dear ImGui 1.80 WIP (17905)
sizeof(size_t): 8, sizeof(ImDrawIdx): 2, sizeof(ImDrawVert): 20
define: __cplusplus=199711
define: linux
define: GNUC=5
define: IMGUI_HAS_VIEWPORT
define: IMGUI_HAS_DOCK
io.BackendPlatformName: imgui_impl_glfw
io.BackendRendererName: imgui_impl_opengl3
io.ConfigFlags: 0x00000000
io.ConfigViewportsNoDecoration
io.ConfigInputTextCursorBlink
io.ConfigWindowsResizeFromEdges
io.ConfigWindowsMemoryCompactTimer = 60.0f
io.BackendFlags: 0x0000140E
HasMouseCursors
HasSetMousePos
PlatformHasViewports
RendererHasVtxOffset
RendererHasViewports
io.Fonts: 1 fonts, Flags: 0x00000000, TexSize: 512,256
io.DisplaySize: 1515.00,1547.00
io.DisplayFramebufferScale: 1.00,1.00
style.WindowPadding: 8.00,8.00
style.WindowBorderSize: 1.00
style.FramePadding: 4.00,3.00
style.FrameRounding: 0.00
style.FrameBorderSize: 0.00
style.ItemSpacing: 8.00,4.00
style.ItemInnerSpacing: 4.00,4.00