(WIP) Dynamic glyph rasterization and unlimited number of font textures #3471
Conversation
Texture baked anti-aliasing and freetype is not yet supported. Only GLFW-OpenGL2 and GLFW-OpenGL3 backends supported.
|
Great work, thanks for posting this! I haven't dug in this, but some early suggestions:
|
|
Thank you for the feedback Omar. I have added FIXME-DYNAMICFONT comments in the places where I soon intend to fix features. The remaining commented blocks are for CustomRect and baked antialiased lines which is not yet supported. I think the flickering is because I am currently generating glyphs in one frame and uploading to the graphics card in the next frame but this should be easy to fix by uploading at the end of the current frame instead. |
…obal define IMGUI_ENABLE_FREETYPE to enable it and disable stb_truetype.
|
I noticed in a gif you posted that it fallbacks to many textures, but then how are drawcalls handled? Wouldn’t this lead to drawcalls explosion very fast? |
… requested glyph has not yet been rendered.
|
There is only one draw call per font texture used. I have not implemented resizing font textures yet since I thought multiple font textures would still be a prerequisite to make it scalable since there is a limit how large a texture can be but no limit on how many textures there can be. ImFont::RenderText works like this: (lines correspond to latest commit 986738c)
In summary:
My latest push fixes the flicker issues. |
Great!
I think the the draw call explosion would be so problematic it is saner to focus on a system when we either
But to be z-order preserving that's per call to RenderText()? And we want to support thousands of calls to RenderText() every frame, interleaved with shapes. To minimize it guess we could have a scheme were:
I've added you the imgui_dev/ repository btw, when you run test_app under "Perfs" you can run perf tests (and probably add new ones) to compare branches, a critical part of this feature is and has always been performance of CalcTextSize() and RenderText() in the normal idle rendering case, for both Debug and Optimized builds, so it would be good to have early metrics of how the current version fare and see if we are within an acceptable ballpark for perfs. Thanks! |
imgui_draw.cpp
Outdated
| result = &this->Glyphs[i]; // Save the result | ||
| if(!backup_glyph) break; //Caller didn't want a backup glyph | ||
| if((this->Glyphs[i].FontTexture && this->Glyphs[i].FontTexture->TexID != NULL) && this->Glyphs[i].FrameCountCreation != ImGui::GetFrameCount()) { | ||
| *backup_glyph = NULL; // This glyph has already been rendered and uploeaded to the graphics card. No backup glyph needed. |
There was a problem hiding this comment.
| *backup_glyph = NULL; // This glyph has already been rendered and uploeaded to the graphics card. No backup glyph needed. | |
| *backup_glyph = NULL; // This glyph has already been rendered and uploaded to the graphics card. No backup glyph needed. |
I will focus on garbage collection and rearranging the glyphs to allow them to remain on the first font texture. These are the results I get when comparing to vanilla imgui. Am I reading it right that my version in -O3 is about a millisecond slower per frame? Since the tests results are similar when displaying proggy-clean on texture 1 and roboto-medium on texture 2 in release mode I think it is an indication that most of the disparity compared to master are optimizations I have not yet implemented. With master imgui -O0 (Debug): With master imgui -O3 (Release): With dynamic fonts -O0 (Debug): (Proggy-Clean on font texture 1) With dynamic fonts -O3 (Release): (Proggy-Clean on font texture 1) With dynamic fonts -O0 (Debug): (Roboto-Medium on font texture 2) With dynamic fonts -O3 (Release): (Roboto-Medium on font texture 2) |
Thanks for the update! Yes that's correct. Another way to read it is to state it is currently about 2-2.5 slower in both -O0 and -O3. For info, the Perf function measure the base dt before starting the test, so the time display is the added difference from that baseline (actual app may be e.g. an extra 1 ms to do the swap etc.). Those specific four tests are stressing one specific aspect - hammering text functions only. Since this is not really what a real app does, maybe we'd get more real-world representative number by running the Later on, another test which will be worth pursuing will be with lots of glyphs (e.g. rendering a typical of Chinese text) as with the new algorithm the hashing will be stressed a little more. Depending on how it far we can adjust the hashing, or perhaps even have specialization for ascii ranges of if find it is worth it. (hope we can later work on systems to turn that CSV data into easy to visualize stuff) |
|
FWIW: I just found this header-only font library tonight that seems amazingly close to the overall architectural methodology of Dear Imgui. It's quite different from what you're doing in this PR but might still be an interesting read... https://github.com/kv01/ttf-parser - Seems like a mature abandon'ed project... I really don't know much about how the font stuff works. Might be a complete waste of time. But anyway. Just trying to be friendly and pass something interesting along. It's about a thousand lines, comments and all, so should be a quick read. License is identical too so you are free to "borrow code" if it does end up being useful. If it helps ,great. If it's a distraction, sorry about that... In any case, keep up the good work. Looking forward to dynamically re-sizable fonts!! |
|
I left a PR on how to change the makefile to detect debug mode on Linux. I don't think you can do it only using a #define. frink: Thank you, but that looks like a parser of .ttf-files and I am still using STB or optionally Freetype for rendering those like vanilla imgui. This branch is about how imgui could handle the generated glyphs on the font texture to display them in different sizes while remaining fast. So it is a step after the library you are linking to. Freetype is a heavier dependency but more visually pleasing and the industry standard. |
|
Yes it is a parse that parses straight to GL triangles if I understand correctly. Not sure if it's better. Just different. First time I've seen GPU engaged to rasterize fonts. My thought is that if we're using GL for everything already why rasterize fonts as an intermediary step? You've probably got a better but it seemed like an interesting idea... |
|
Any news on when this will be merged? This is exactly what I need. |
Could be a while. Good code takes time and this one is no picnic. Right now the best thing you can do is oversample your font atlas in the init stage and then use font scaling. |
time. When the primary font texture is full overflow font textures are used to render the remaining glyphs. On the next frame all glyphs are cached and a new primary font texture is assembled with the glyphs from the cache. Changes to be committed: modified: examples/imgui_impl_opengl2.cpp modified: examples/imgui_impl_opengl3.cpp modified: imgui.h modified: imgui_demo.cpp modified: imgui_draw.cpp
|
In the latest update only one font texture is used 99% of the time. When the primary font texture is full glyphs spill over to overflow texture(s). On the next frame all glyphs are moved to a cache and the font atlas re-assembled with the custom rects and the currently visible glyphs. This is ocornut:master on my machine: This is the dynamic font branch on my machine (no glyph overflows triggered): |
Upgraded to v 1.84 WIP.
|
I'll be resuming work on a similar feature in the upcoming few months. The truth is that we've accumulated 3-4 solid chunks of work related to this (incl this PR and e.g. #3761 which is one back-bone of this + various private bits of work). But there are hundreds of important decisions I need to nail right and very precisely. So I'm basically starting from scratch again but I will be referring to all past work whenever I wonder how something was approached or solved. Thanks for this! |
|
I'm trying to make use of this pull request until official support for this is added. It works just fine except for one really annoying and probably easy to fix bug: Rounded frames always have a blackish hue to them and sometimes even parts of the non-rounded frame completely disappear. Tried glfw opengl3 and opengl2 renderers, both have the same issue. Everything else seems to work perfectly fine so I'm very confused. This is a minimal example just using Begin()/Button("test")/End() Thanks for the work @georgegerdin by the way, this would be a godsend for me if it weren't for that small bug. Unfortunately I'm not that well versed with deep imgui internals yet but I'll continue to try and find the cause for a little while. I'll let you know should I find anything |
|
While I haven't found the cause yet, here is some more information. Dx9 renderer has the same behavior, and here's some reproduction code (ploppoed right into the imgui examples): ImGui::Begin("test window");
const ImVec2 pos = ImGui::GetCursorScreenPos();
ImGui::GetWindowDrawList()->AddRect(pos, { pos.x + 50.f, pos.y + 50.f }, IM_COL32(200, 200, 200, 255), 4);
ImGui::End();Which results in this: |
|
Found a workaround, |
|
I have pushed a fix 6c8b46e for the issue your reported. |
FYI for clarity I ran basic performance tests on this: ImVec2 p = ImGui::GetCursorScreenPos();
for (int n = 0; n < 5000; n++)
{
ImGui::SetCursorScreenPos(p);
ImGui::Text("This is some useful text.\nhfds3714u24i2orwrjijIJ@I!IJ!J#!#J!");
}I am unfortunately unable to consider a PR with those performances characteristics. (I am also unfortunately unable to thoroughly review PR not following the coding style. I sincerely wish I had the mind and brain to overlook this but I am unable to, my brains gives up easily) |
be located on the first font texture.
the end of the frame.
|
It's disappointing it is still too slow. Here are the latest perflogs on my machine if they are of any use - looks like it is a lot slower than when I last tested it in the test engine: master: Dynamic fonts: |
|
One question: Freetype support was supposedly added in commit 58b51b1. Yet, including imgui_freetype.cpp results in an error in |
|
FYI i've been working on a reimplemention of this and expect a public beta branch to be avail before end of the month. |
No, but perhaps unobservant. This branch is somewhat out of date. It sounds like we have much to look forward to in the new year, perhaps even a wonderful Christmas present. I feel that I can hardly wait. BTW, for my project I decided to use the Unicode CLDR database to inform the font atlas I build. This database has a list of characters used by each locale’s script(s), so I add the characters from the locale corresponding to the selected translation to the atlas, along with the default characters and a selection of arrows, superscripts, and a few other things. Even once dynamic glyph rasterization is available we’ll probably still build the default atlas the same way. Dynamic glyphs will just be used when the user happens to type in something unexpected. |
On the offchance that anyone wants to use FreeType with this... The ImFontAtlasBuildWithFreeTypeEx and related functions can simply be deleted as they're not called anymore. |
|
I've noticed a fairly deal-breaking bug about this branch. Those are supposed to be some numbers. Mind you, this happens without any change in the executable. Not sure if this is really worth looking into considering @ocornut mentioned an eventual official implementation of this. |
|
Well, as an update, the aforementioned issues only occur with the FreeType implementation (IMGUI_ENABLE_FREETYPE). I'll invest some time to try and get to the bottom of it |
|
With the power of more hindsight, I can conclude that the crashing issues are fixed without FreeType but not the mangled text. |
|
Closing this as we'll be moving into #8465, current WIP 2025-01-27.font.resize.mp4The general performance characteristics are that for a typical idle-frame with no new glyphs, things are expected to be about 1-2% slower. Actual glyph baking, packing, atlas compacting/repacking/copying etc operations are of course slower but they tend to be amortized really quickly. The worst-case-ish scenario of continuously zooming a bunch of Chinese text can still run at interactive framerate but is not expected to be super fast if large sizes are not in cache. Typical EFIGS languages or even Japanese are likely to not encounter meaningful performances issues. |
This PR is my attempt at bringing dynamic glyph rasterization and unlimited number of font textures to Dear ImGui. This is my proposal to fix #3365 #3406 #797 and all issues related to chinese glyphs, japanese glyphs etc...
Only the glfw_opengl2 and glfw_opengl3 backends are currently supported. The directx backends where changed to let me compile the example but do not work. I intend to fix them but wanted to show you my results before I get time for that. Tested on windows. Freetype, baked anti-aliased lines, software rendered mouse cursor and custom rects are not yet supported. The white pixel is located at (0, 0) on all generated font textures.
ImFontAtlas and ImFont has been completely revamped to generate glyphs upon use and packed in the same manner as fontstash. The rendering of the final text is the same as normal Dear ImGui. Instead of each font atlas having a personal FontSize the ImFontAtlas has a FontSize common to all loaded fonts.
Future plans is adding the missing features from normal Dear ImGui font code and unloading glyphs that have not been used for a certain amount of time.