Inconsistent FPS Label Behavior After Error and Rotation

[ImDiM]

Version: 2.35.0 (87), 2.36.1

Description:
After a syntax error occurs, the FPS label in the top-left corner becomes static instead of disappearing. After rotating the device, the FPS label disappears entirely.

Steps to reproduce:

1. Observe that with correct code, the screen background is green and the FPS value in the top-left corner updates dynamically
2. Modify the code to introduce a syntax error — the background turns black and the FPS value becomes static but does not disappear
3. Rotate the device to landscape mode — the background remains black and the FPS label in the top-left corner disappears

Expected behavior:
In portrait mode, after a syntax error occurs, the FPS label in the top-left corner should disappear instead of becoming static, and its behavior should remain consistent after rotation.

[markusfisch]

Well, if there’s an error, the shader isn’t running and so there aren’t any frames per second rendered.

The frames per seconds display is always measured in real time, and stays visible, on the latest value, when rendering stops because of an error, for example. When the device is rotated, the display is rendered completely anew (this is the default Android behavior) without any previous value for frames per second for that new display configuration.

So while I can see why this can look inconsistent and irritating, it’s really just the way things work 😉

[ImDiM]

Thank you for the detailed explanation. I completely understand that the current behavior is a result of the Android Activity recreation process.
However, from a UI/UX consistency perspective, the discrepancy between portrait and landscape modes (one showing the last stale value and the other showing nothing) might be confusing for users.
To ensure a more consistent experience, would you consider either:

• Uniformly hiding the FPS counter when an error is detected?
• Persisting the last FPS value (e.g., via ViewModel or onSaveInstanceState) so it remains visible after rotation, even if rendering has stopped?

I am currently documenting this specific UI behavior and its technical constraints in my thesis. I would appreciate your thoughts on these suggestions, as your confirmation or perspective would be a valuable addition to my research.