Bad performance for boundaries

[alex-w]

Expected Behaviour

Good performance to rendering boundaries of constellations

Actual Behaviour

Bad performance to rendering boundaries of constellations - after enabling displaying boundaries FPS dramatic decreases in 4 times

Steps to reproduce

1. Run Stellarium
2. Enable boundaries (B)

System

• Stellarium version: master
• Operating system: macOS 13.0 M1

Logfile

log.txt

[10110111]

Does this also happen with --opengl-compat option?

[Atque]

Also to some degree present on Windows. Especially noticeable at wide FOV.

[alex-w]

Does this also happen with --opengl-compat option?

No

[github-actions]

Hello @alex-w!

OK, developers can reproduce the issue. Thanks for the report!

[alex-w]

@10110111 any ideas where is the source of issue?

[10110111]

Apparently, the geometric shader works slowly. But it's so basic, that I don't know how it could be optimized.
A solution of this issue would be to redo StelPainter::drawFromArray() for all line-based primitives, so that it created polygons on the CPU instead of the geometric shader. Not nice technically, and quite a bit of work.

[alex-w]

Today we tested 1.2RC2 on Intel Mac and the issue is not reproducible, so, apparently this is problem specific for arm-macs (at least for M1).

[gzotti]

I can confirm the boundaries are "expensive" also on Win11, dropping from 60 to 52 fps in wide-angle view. But also gridlines, GUI dialogs and InfoText displays are (and always have been) costly. I have not tested previous versions on this notebook, though. A drop to 1/4 would be bad, indeed. Is that only boundaries, or also the gridlines?

[unpacklo]

The core issue is the CPU cost here in drawing lines and text:

We should not be creating a new QOpenGLPaintDevice in StelPainter::drawText. The destruction of QOpenGLPaintDevice is 11% of the total CPU time. I've spent some time before in this code in an attempt to optimize a few months ago but I simply don't have enough knowledge about how Qt's OpenGL API and how Stellarium works to be able to meaningfully contribute at this time.

Aside from that, the text drawing appears to be the most costly and should be addressed, but I haven't figured out what the core cause is of the slow performance to have any suggestions about making the text draw faster. I suspect it is due to constant rerasterization or recomputation of the layout of the text but I'm not sure. More profiling will be needed.

[10110111]

We should not be creating a new QOpenGLPaintDevice in StelPainter::drawText.

This might be one of the reasons, but not the only one. Lines used to work faster. But, do you get any improvement if you make this variable static?

[unpacklo]

I finally managed to build stellarium on my macos and I can confirm that simply making the variable static makes my frame rate go from about 7 FPS to about 20 FPS (from about 143 ms per frame to about 50 ms per frame) for about a 2.8x speedup. Totally worth doing, but given that the CPU time associated with the destructor only takes up 10%, there must be some sort of GPU pipeline flush or sync that occurs with the construction/destruction of the QOpenGLPaintDevice that causes a much larger performance problem on the GPU side. I'll try to dig more but simply making that var static has a really big boost.

[10110111]

I finally managed to build stellarium on my macos and I can confirm that simply making the variable static makes my frame rate go from about 7 FPS to about 20 FPS

This is not related to boundaries, right? Because I don't see any text associated with them.

[alex-w]

@unpacklo thank you for investigating the problem. Could you send us pull request with patch?

[unpacklo]

I finally managed to build stellarium on my macos and I can confirm that simply making the variable static makes my frame rate go from about 7 FPS to about 20 FPS

This is not related to boundaries, right? Because I don't see any text associated with them.

@10110111 ah sorry, I was confused with another issue. I don't see the problem with boundaries at the moment, but I am seeing big performance problems on my Intel MacBook Pro (2019).

@unpacklo thank you for investigating the problem. Could you send us pull request with patch?

@alex-w Yes, I intend to open a PR once I've figured out why making it static improves performance so much.

[krstnrogers]

Very slow and lags on version 1.2 when enabling the "show boundaries" option. Macbook air running MacOS Ventura 13.2.

[alex-w]

This is weird. macOS 13.2.1 (M1), current master + Qt5 - no penalty of performance when boundaries are enabled. Current master + Qt6 - the issue is here.

[gzotti]

We can so much need a profiling expert to point out bottlenecks!

[10110111]

One major difference between Qt5 and Qt6 is that in Qt5 only integral scaling factors are supported (any fraction is rounded), while Qt6 supports fractional factors. You might be observing no slowdown with e.g. 100% effective (i.e. from Qt's PoV) pixel ratio, while a slowdown appears with higher pixel ratio.

[alex-w]

One major difference between Qt5 and Qt6 is that in Qt5 only integral scaling factors are supported (any fraction is rounded), while Qt6 supports fractional factors. You might be observing no slowdown with e.g. 100% effective (i.e. from Qt's PoV) pixel ratio, while a slowdown appears with higher pixel ratio.

But why Qt6-based packages doesn't have the issue on Mac's with Intel CPU?

[10110111]

If the issue only appears on non-Intel, this may just mean that Intel have been capable of making GPUs that run geometry shaders with sensible performance.

Just to check, what pixel ratio do you have on the machines where this slowdown happens? I'm interested in both Qt5 and Qt6 perspectives. Also, was the line width setting changed from the default on these machines?

[alex-w]

Device pixel ratio is 2

[10110111]

In both cases?

[alex-w]

In both cases?

Yep

[github-actions]

Hello @alex-w!

Please check the fresh version (development snapshot) of Stellarium:
https://github.com/Stellarium/stellarium-data/releases/tag/weekly-snapshot

[github-actions]

Hello @alex-w!

Please check the latest stable version of Stellarium:
https://github.com/Stellarium/stellarium/releases/latest