Dynamic switching between exclusive and managed full screen mode

[uwes-ufo]

Description

In addition to #2619, this pull request offers dynamic switching between exclusive and managed fullscreen modes. This can be done by right-clicking the fullscreen button or by pressing Shift+F11.

Currently, switching between exclusive and managed fullscreen modes results in a brief screen flicker. Because exclusive fullscreen mode offers limited window functionality, the screen flickers every time, for example, a tooltip appears. #2619 keeps the screen permanently in managed fullscreen mode, thus preventing the flickering. Exclusive fullscreen mode, on the other hand, offers better performance, which translates into potentially higher frame rates.

I know the implementation is somewhat unusual… I based it on this Stack Overflow question.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• This change requires a documentation update
• Housekeeping

How Has This Been Tested?

Test Configuration:

• Operating system: <Name, version number>
• Graphics Card: <Manufacturer (likely Intel, NVidia, AMD?), Model (HD, Geforce, Radeon..., with model number), driver version?>

Checklist:

• My code follows the code style of this project.
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (header file)
• I have updated the respective chapter in the Stellarium User Guide
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[github-actions]

Great PR! Please pay attention to the following items before merging:

Files matching src/**/*.cpp:

• Are possibly unused includes removed?

This is an automatically generated QA checklist based on modified files.

[uwes-ufo]

The change to src/gui/locationDialogGui.ui doesn't seem to be related. I'll check it out...

[10110111]

Exclusive fullscreen mode, on the other hand, offers better performance, which translates into potentially higher frame rates.

The change looks quite hacky. Do you actually get any tangible benefits from this mode?

[10110111]

Graphics Card: <Manufacturer (likely Intel, NVidia, AMD?), Model (HD, Geforce, Radeon..., with model number), driver version?>

I'd rather have this filled...

[uwes-ufo]

This PR addresses the same issue as #2619. It resolves issues #2166, #2472, and #2484. It's again Windows on an Intel UHD 620. Here, you tested the issue and asked how it works. I don't know the exact details either, but in my opinion, the number of buffers used is irrelevant to this problem. The single buffer has the side effect of permanently putting the graphics card into managed fullscreen mode, thus preventing a switch between exclusive and managed modes, which would trigger the flickering.

The change looks quite hacky.

Ja! It's strange, at the very least. I even find it ugly.

Do you actually get any tangible benefits from this mode?

• Managed mode has no blinking effect.
• Exclusive mode is faster.

[10110111]

Exclusive mode is faster

How much faster?

[uwes-ufo]

• 60 BPS to 40 BPS without atmo
• 40 BPS to 30 BPS with atmo

on my hardware.

[alex-w]

• 60 BPS to 40 BPS without atmo
• 40 BPS to 30 BPS with atmo

on my hardware.

What about BPS without patch?

[uwes-ufo]

• no --single-buffer ~> exclusive fullscreen ~> blink effect + sometimes no mouse pointer

• • without atmo - 60 fps
• • with atmo - 40 fps

• --single-buffer ~> managed fullscreen ~> no blink effect + reliable mouse pointer

• • without atmo - 40 fps
• • with atmo - 30 fps

This pull request provides an alternative to --single-buffer, which can be toggled during Stellarium's execution.

[10110111]

So basically, this PR makes it possible to switch between different broken states: one blinking, another 25% slower.

Have you tried reaching out to Intel? Maybe they could provide a real fix for their drivers (they might not even know of the blinking problem). No other vendor has this blinking problem, neither should Intel.

[10110111]

I wonder if we can, instead of all this hackery, just force the tooltips to be parts of the scene, just as most of the other dialogs.

[uwes-ufo]

I wonder if we can, instead of all this hackery, just force the tooltips to be parts of the scene, just as most of the other dialogs.

That would be an elegant solution to the problem.

I've noticed something else: Sometimes there's no mouse pointer in exclusive fullscreen mode, but the mouse works when you use it blindly.

[gzotti]

That's a very old FAQ. Do you have some software cursor enabled like "mouse trail"?

[uwes-ufo]

I have two practically identical laptops; all the software is essentially cloned. On one computer, the mouse cursor disappears, but not on the other...

I can confirm that the problem with the mouse pointer is related to the mouse trail.

[10110111]

Apparently, it is possible to have scene-based tooltips. For this QGraphicsScene::helpEvent in StelGraphicsScene should be overridden to show the tooltips in a custom way.

[10110111]

Note that the default tooltips have some special features like animation of one tooltip position into another when moving cursor from one control to another (instead of disappearing and appearing in the new place), as well as fade-in and fade-out effect (at least under KWin, and we have similar animations for screen buttons). These shouldn't be lost when the custom tooltips are implemented. But of course, a proof of concept could ignore these.

[10110111]

I've made a proof of concept for the in-scene tooltips, see #4704.

[uwes-ufo]

#4704 looks promising.

I've restored the original tooltips in managed fullscreen mode for debugging purposes, for easier comparison.