-
-
Notifications
You must be signed in to change notification settings - Fork 10.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimization question: Is there a way to compute only the "visible" portion of data for submission to ImGui? #124
Comments
If you are dealing with thousands of entries you probably want to perform clipping yourself, yes.
From there on
Let me know if that is confusing. I will look into simplifying this process with the right helpers (if you have any suggestion). Note that TextUnformatted() does something similar for you when you pass it large blurb of text. However aside from the clipping the Columns API is currently unbearably slow, which is also something I ought to look into. But it shouldn't be a problem at this scale once you implement the clipping. |
I have added a helper function _CalcListClipping()_ to do that
Here's my test code
With manual clipping the framerate gets back to the maximum I get in the test application with my drivers (~2000 fps on DX11 sample). Adding UTF-8 support and other features still put a bit of a hit on performance for normal Text calls. They should be lighter when not manually clipped so I will work on that next. |
Moving discussion to another thread and closing this specific issue (Columns are a bunch of issues!) " ImGui::Columns(1); |
I've added a gist just to consolidate and generalize the code posted by Roflraging. https://gist.github.com/Flix01/94b0bf3069476a1344ac UPDATE: improved gist a bit adding basic cell text formatting, optional column reordering (programmatically) and row sorting by clicking on the column headers. UPDATE 2: added (single) row selection support and cell editing support. I think I'll stop developing it for now: I've added all the features I needed. |
I'm not sure about that. It seems to defeat a lot of the ImGui design principles, storing and retaining thing prior to display. Notice how the original code is shorter than even your examples code - let alone the base classes you are using - and more flexible as well. So in my eyes it looks like an unnecessary abstraction to "consolidate" it that way. I do agree that the Column API need improvements, we will probably end up implementing the features discussing above and simplify user's code so that headers can be declared with less code. We keep hammering the API to be more flexible more optimal more terse. |
Yes, I know. It's not my intention to integrate my gist into ImGui. I just want to try to have more complete controls, without caring about the fact that they comply with the ImGui design principles or not. |
I went back to that from the different angle, which is that I want to make things faster even with zero clipping on user's side. So I looked at some of the primitives involved in the bottleneck and optimised them. My test code displaying 12000 lines, 4 items and columns per line (so about 48000 submissions) went from 36.1 ms to 27.6 ms for an optimised build, and 288 ms to 195 ms for a non optimised build. Of course it isn't a very meaningful scenario, since with the user's coarse clipping enabled time gets back to near 0.0 anyway. But this optimisation should benefit every part of ImGui. |
FYI i have added a higher level helper ImGuiListClipper to handle this pattern. So this code above int displayStart = 0, displayEnd = pack.manifest->numPaths;
ImGui::CalcListClipping(pack.manifest->numPaths, itemHeight, &displayStart, &displayEnd);
ImGui::SetCursorPosY(ImGui::GetCursorPosY() + (displayStart * itemHeight));
for (int i = displayStart; i < displayEnd; ++i)
[...]
ImGui::SetCursorPosY(ImGui::GetCursorPosY() + ((pack.manifest->numPaths - displayEnd) * itemHeight)); Can become ImGuiListClipper clipper(pack.manifest->numPaths, itemHeight);
for (int i = clipper.DisplayStart; i < clipper.DisplayEnd; ++i)
[...]
clipper.End(); CalcListClipping() is still available as the lower level function. |
Hi Omar,
I've been working on a small data packer tool with a GUI element to see the contents of the pack file. Our game currently has around ~12,000 files that need to be processed in some way and I show the contents of the pack file like so:
The overall layout of the window is very predictable and all data is indexed via simple array accesses.
Right now I just iterate over all the contents of the pack file and submit everything to ImGui. Obviously, with as many items in the pack file as I currently have, the performance is low. Is there some way for me to determine some bounds of the visible contents of the window and still scroll properly so I can keep high perf?
Thanks again, keep up the awesome work!
-Dale Kim
The text was updated successfully, but these errors were encountered: