feat: implement subpixel rendering #2092
Draft
+231
−41
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Proof of concept for implementing subpixel processing in ImGui. This is work in progress, and it is bound to have problems. What it does: 1) Uses freetype own subpixel processing implementation to build a 32-bit color atlas for the default font only (no icons, no unifont) . 2) Avoids pixel perfect font conversion when possible. 3) Self contained, no ImGui source code changes. 4) Results in much improved legibility of fonts rendered on low dpi LCD screens that use horizontal RGB pixel layouts (no BRG or OLED or CRT if they even exist anymore) What it doesn't: 1) Fancy class based interface. The code is barely the minimum needed to show it can work. 2) Dual source color blending. That needs to be implemented in shader code, so it needs to change ImGui source code although minimally. This will result in some characters appearing dimmer than others. Easily fixed with small fragment and vertex shaders. 3) subpixel positioning. If characters are very thin they will look colored, or they can be moved to improve legibility. 4) deal with detection of fringe cases including rare pixel layouts, non LCD screens, Mac-OS not handling subpixel rendering and any other deviation from the standard LCD. 5) tries to be efficient in speed or memory use. Font Atlases will be 4 times the size they were before, but there are no noticeable delays in font loading in the examples I have tried. Any comments and code improvements are welcome.
Icons become unaligned because the default font's descent is not calculated until the atlas is built. Atlas building must be delayed until custom rects are defined and besides, building an atlas just to obtain the descent is something that ImGui font implementation makes necessary. All font and glyph metrics are accessible when they are loaded by specifying some desired size using the freetype api. It takes a little bit of extra code, but it is the most efficient way to obtain metrics.
The dual double loop done inside the final rendering, one to remove the padding and the other to move the data to the atlas rect have been merged into one double loop that loads the atlas data directly from the bitmap saving time and memory. The dual glyph rasterization, one during rect creation and the other during Atlas final data write have also been made more efficient. All the bitmaps are saved into a map from rect id to bitmap. In the debug version on my slow computer fonts load in about 4 seconds. In comparison, a nightly takes about 2 seconds.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Proof of concept for implementing subpixel processing in ImGui. This is work in progress, and it is bound to have problems.
What it does:
What it doesn't:
Any comments and code improvements are welcome.