What kinds of StelPainter-based text do we have?

[10110111]

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:

• Make use of the --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:
  • a problem of positioning, where it appears that QFontMetrics don't agree exactly with QPainter::drawText, so the results of --fix-text and normal text rendering differ;
  • rotated text is currently implemented by rotating a cached texture of non-rotated text, which degrades quality;
  • finally, subpixel smoothing doesn't work in this case (this might be solvable, but not with the rotation as implemented currently).
• Render the text as a separate pass, into the final sRGB framebuffer. This approach has another problem: while the rendering of cardinal direction markers could be done this way, most of the text like planet names, DSO markers etc. is behind the landscape. This makes it necessary to somehow combine sRGB-based QPainter rendering with linear-color scene rendering, switching back and forth, which will have a performance cost because of blitting from linear framebuffer to sRGB one (or backwards, because we want linear blending, which would only work with the linear framebuffer).
• Try using an sRGB framebuffer. This also has problems:
  • GLES API doesn't have 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;
  • any future changes to implement HDR rendering will be done in a linear color space anyway, so this is a dead end;
  • dithering is harder to implement.

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.

[alex-w]

Formally the text rendering doing in layers by getCallOrder() rules.

[gzotti]

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.

[10110111]

So, can you wrap a color transform in the setColor() call that usually goes ahead of text drawing?

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.

[10110111]

Formally the text rendering doing in layers by getCallOrder() rules.

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.

[gzotti]

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?

[10110111]

there is another layer in the Scenery3D module that is drawn after landscape

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.

[10110111]

Can you show how such gamma-incorrect antialiased text may look like in the end?

For comparison, old (the text as it's supposed to be):

And new (gamma-incorrect text):

So it basically looks as if bold, especially when font size is small.

[gzotti]

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.
Text and line colors can be configured to something slightly darker, so there are many ways to fine-tune. Make sure the color selection buttons look like the final target colors, though.

[10110111]

For me the difference looks like that for the new DSO icon lines.

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.

Make sure the color selection buttons look like the final target colors, though

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 StelPainter-rendered text.

[10110111]

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.

[gzotti]

There is a cutoff altitude described on pp. 75/76:

minimal_altitude (optional, default=-2) Some sky elements, e.g. stars, are not drawn below this altitude for efficiency. Under certain circumstances (e.g. for space station panoramas where you may have sky below your feet, or for deep valleys/high mountains, you may want to specify something else here.

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.