-
-
Notifications
You must be signed in to change notification settings - Fork 809
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
What kinds of StelPainter-based text do we have? #3213
Comments
Formally the text rendering doing in layers by |
Is linear vs. sRGB in essence not just a color transform? So, can you wrap a color transform in the setColor() call that usually goes ahead of text drawing? The --fix-text was an ugly kludge to make text visible at all when the OS's OpenGL engine was broken. So, nice looks were never a topic. |
I have done it, but this is only sufficient for non-antialiased text. When we use antialiasing (and we should always use it), the result—the antialiasing gradients—becomes gamma-incorrect when interpreted as linear color. |
Yes, but I'd like to keep the number of text layers to a minimum to minimize the amount of blitting back and forth. Besides, call order is per-module, and each module can render both text and physical objects. |
If you want to explore the accumulation into "sky" text and "landscape" text, there is another layer in the Scenery3D module that is drawn after landscape. It can show coordinates in the top-right corner. But generally, this seems to make the general module design yet more complicated. I agree that we need antialiasing. Can you show how such gamma-incorrect antialiased text may look like in the end? |
If you mean that it's drawn basically after all the physics is complete, then it'd be the same layer as cardinal direction markers. |
For me the difference looks like that for the new DSO icon lines. There is no color fringe or anything bad. It's a tick heavier, but not yet boldface. I think I could live with that. |
Exactly, but there's a catch: for the OpenGL-rendered antialiased geometry the change is good, i.e. it makes the result more correct, because OpenGL had never been aware of sRGB EOTF until corresponding extensions appeared. But the text rendering engine (FreeType etc.) was already designed with gamma correctness in mind, so the change for the glyphs is bad, since it effectively applies OETF twice: first time FreeType does it, second time my blit.
The GUI shouldn't be affected by this change, so I wouldn't worry about it. I just don't like that it's incorrect when it comes to |
I noticed that when the ground is rendered (fully faded in), the stars below the horizon are hidden, but the planets are still visible. Does this serve any purpose, or is it just an artifact? If the planets should also be invisible, then it seems the only text layer we need is actually the one on top, and we can let the labels that are currently hidden by e.g. trees shine on top of the scenery, rather than remain hidden behind. |
There is a cutoff altitude described on pp. 75/76:
For stars, they are clipped away for efficiency. For the other objects, probably it did not pay off to do so, but I don't remember if we exclude e.g. DSO as well. |
During the development of #3156 I found a problem with text:
QPainter
doesn't have any way to be made aware of the linear color space used in the underlying framebuffer. So I considered a few ideas:--fix-text
mode, restoring antialiasing (which would be disabled if--fix-text
command line option was passed) and fixing its look with high-DPI scaling. This has some issues:QFontMetrics
don't agree exactly withQPainter::drawText
, so the results of--fix-text
and normal text rendering differ;gl{En,Dis}able(GL_FRAMEBUFFER_SRGB)
that desktop GL has. And lack of this API means that QPainter renders in sRGB color space, while the framebuffer writes automatically convert the values assuming they are linear;So, my question now: how many kinds of
StelPainter
-based text do we have? Are the two parts, "behind the landscape" and "in front of landscape" all that we have? Or do we have any other text layers hidden by some other objects?If it's just two layers, then maybe I could just order the rendering in such a way that background text would accumulate, then the whole layer would be blitted, and the foreground text would be just rendered after the whole scene is done.
The text was updated successfully, but these errors were encountered: