Skip to content

Conversation

@uwes-ufo
Copy link
Contributor

@uwes-ufo uwes-ufo commented Nov 27, 2025

Description

Fixes # (issue) avoid initial delay and improve the comprehensibility of the implementation

Screenshots (if appropriate):

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
Copy link

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.

@alex-w
Copy link
Member

alex-w commented Dec 1, 2025

I see no visual difference

@10110111 please check this pull request

@10110111
Copy link
Contributor

10110111 commented Dec 1, 2025

What role does dynResTimer play after this patch? It doesn't seem to affect anything in the remaining logic.

@uwes-ufo
Copy link
Contributor Author

uwes-ufo commented Dec 1, 2025

// if we don't have a timeout or too much change, we skip the frame
return true;

void AtmosphereShowMySky::computeColor
...

if (dynamicResolution(prj, sunPos, width, height))
			return;

we leave void AtmosphereShowMySky::computeColor before anything happens... (skip)
reduces cpu load (without that, my little laptop would burn down)

dynResTimer=changed?5:17;

If the scene is rendered in real time and is practically static, Stellarium generates approximately 18 frames per second. We draw about one atmosphere per second at full resolution. For faster-moving scenes, Stellarium increases the frame rate to the maximum, perhaps 50 frames per second depending on the hardware's capabilities. We draw about 10 atmospheres per second in reduced resolution.

dynResTimer is like a clock divider.

@alex-w alex-w added this to the 25.4 milestone Dec 1, 2025
// if there is a timeout, we draw with full resolution
// if the change is too large, we draw with reduced resolution
atmoRes=timeout?1:reducedResolution;
// if the change is too big, we draw with reduced resolution, otherwise with full resolution
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Honestly, the previous comment was a bit more understandable. I think the following would be better:

If the change is too big, the scene is considered dynamic and needs a higher frame rate, so it's rendered in lower resolution. Otherwise there's been a timeout, so the scene is updated in full resolution.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@10110111
Copy link
Contributor

10110111 commented Dec 2, 2025

Aside from my comments on comments, this LGTM.

@uwes-ufo
Copy link
Contributor Author

uwes-ufo commented Dec 2, 2025

I am completely flexible regarding the comments.

This line deals exclusively with the resolution.

// if the change is too big, we draw with reduced resolution, otherwise with full resolution
atmoRes=changed?reducedResolution:1;

This line deals exclusively with the frame rate.

// At reduced resolution, we hurry to redraw - at full resolution, we have time.
dynResTimer=changed?5:17;                                       // dynResTimer is like a clock divider.

The interplay of both factors is illustrated here.

// If the scene is rendered in real time and is practically static,
// Stellarium generates approximately 18 frames per second.
// We draw about one atmosphere per second at full resolution.
// For faster-moving scenes, Stellarium increases the frame rate to the maximum,
// perhaps 50 frames per second depending on the hardware's capabilities.
// We draw about 10 atmospheres per second in reduced resolution.

@10110111 10110111 merged commit d82fb2f into Stellarium:master Dec 2, 2025
15 of 16 checks passed
@github-project-automation github-project-automation bot moved this from Backlog to Done in Atmosphere Dec 2, 2025
@uwes-ufo uwes-ufo deleted the minor_dynamic_resolution_changes branch December 2, 2025 18:37
@alex-w alex-w added the state: published The fix has been published for testing in weekly binary package label Dec 8, 2025
@github-actions
Copy link

github-actions bot commented Dec 8, 2025

Hello @uwes-ufo!

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

@alex-w alex-w removed the state: published The fix has been published for testing in weekly binary package label Dec 29, 2025
@github-actions
Copy link

Hello @uwes-ufo!

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

3 participants