Skip to content

fix(rendering): actually suppress FBO resize-to-zero on minimize - #5372

Open
soloturn wants to merge 1 commit into
developfrom
soloturn-fix-minimize-black-screen
Open

fix(rendering): actually suppress FBO resize-to-zero on minimize#5372
soloturn wants to merge 1 commit into
developfrom
soloturn-fix-minimize-black-screen

Conversation

@soloturn

Copy link
Copy Markdown
Contributor

Fixes #5081 - game screen goes dark after minimizing (via a third-party minimize tool) and restoring.

This is #4980's fix, with an inverted condition

LwjglDisplayDevice.updateViewport already tries to guard against this - added by #4980 for an earlier report of the identical symptom - but the guard never actually worked.

GLFW reports the framebuffer as 0x0 while a window is minimized. DisplayResolutionDependentFbo.propertyChange and PerspectiveCamera's own DISPLAY_RESOLUTION_CHANGE listener both react to the event firing at all, not to its old/new values - propertyChange regenerates every resolution-dependent FBO at whatever size the display device reports at that moment. #4980's intent was to stop that event firing while minimized, using PropertyChangeSupport.firePropertyChange's own behaviour of skipping notification when old equals new as the switch:

boolean isMinimized = GLFW.glfwGetWindowAttrib(...) == GLFW.GLFW_TRUE;
int i = isMinimized ? 0 : 1;
propertyChangeSupport.firePropertyChange(DISPLAY_RESOLUTION_CHANGE, i, 1);

This picks the value backwards: while minimized, i=0 differs from newValue=1, so the event still fires - unchanged from before #4980 landed. While not minimized, i=1 matches newValue=1, so it's suppressed - a second, unrelated regression, since that's exactly when a resize should propagate.

Fix

Flip which value goes with which case: (1, 1) while minimized so the compare matches and nothing fires, (0, 1) otherwise so a genuine resize still does.

What I could and couldn't verify

Root-caused and fixed by reading, not reproduced - confirming this needs an actual Windows session with a real or synthetic minimize gesture, which I don't have here. The fix follows directly from documented GLFW behaviour (0x0 framebuffer while iconified) and PropertyChangeSupport's own equals-based suppression semantics, not from observing the bug happen.

No existing tests cover this class - updateViewport needs a live GLFW window/context, not something headless-testable. :engine:compileJava is clean.

#5081: game screen goes dark after minimizing and restoring, via a
third-party minimize gesture tool (TaskbarX) rather than native
Windows minimize/restore.

This is the same symptom #4980 already tried to fix, and the fix it
shipped has an inverted condition, so it never worked - not for native
minimize either, just less commonly hit.

GLFW reports the framebuffer as 0x0 while a window is minimized.
DisplayResolutionDependentFbo.propertyChange and PerspectiveCamera's own
listener both react to DISPLAY_RESOLUTION_CHANGE firing at all - neither
reads the old/new values on the event, they only care whether it fired -
and propertyChange regenerates every resolution-dependent FBO at
whatever size the display device reports at that moment. So the intent
of #4980's fix was: while minimized, don't let this event fire, so
FBOs never get regenerated at 0x0 and never need to be un-broken on
restore.

PropertyChangeSupport.firePropertyChange suppresses notification when
old equals new, which #4980 used as the on/off switch - but picked the
value that differs from newValue(1) while minimized (0) and the value
that matches while not (1), the opposite of "stop it while minimized".
So minimizing always fired (0 != 1, unchanged from before #4980), while
every ordinary window resize - not just minimize/restore - stopped
firing (1 == 1, newly suppressed), since the value passed no longer had
anything to do with whether the size actually changed.

Flips it: (1, 1) while minimized so the compare matches and nothing
fires, (0, 1) otherwise so a genuine resize still does.

Root-caused and fixed by reading, not reproduced - this needs an actual
Windows session with a real or synthetic minimize gesture, which I don't
have here. The fix follows directly from documented GLFW behaviour
(0x0 framebuffer while iconified) and PropertyChangeSupport's own
equals-based suppression, not from observing the bug.

No existing tests cover this class - updateViewport needs a live GLFW
window/context, not something headless-testable.

Compiles clean (:engine:compileJava).

Fixes #5081

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@github-actions github-actions Bot added the Type: Bug Issues reporting and PRs fixing problems label Aug 19, 2026
@coderabbitai

coderabbitai Bot commented Aug 19, 2026

Copy link
Copy Markdown

Review Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 921fd2d1-05f7-474f-9eb1-c07a22fb5685

📥 Commits

Reviewing files that changed from the base of the PR and between 338d7dd and 89e9094.

📒 Files selected for processing (1)
  • engine/src/main/java/org/terasology/engine/core/subsystem/lwjgl/LwjglDisplayDevice.java

Included review availability: Your plan provides up to 8 included reviews per hour; 6 remain after this review.


📝 Walkthrough

Summary by CodeRabbit

  • Bug Fixes
    • Corrected display resolution-change notifications during window resizing.
    • Resolution updates are now reported normally when the window is active and suppressed while minimized.

Walkthrough

updateViewport(int, int) now suppresses resolution-change notifications while the GLFW window is minimized. During normal resizing, it continues to send genuine property-change notifications.

Changes

Viewport notification handling

Layer / File(s) Summary
Correct minimized-window notification handling
engine/src/main/java/org/terasology/engine/core/subsystem/lwjgl/LwjglDisplayDevice.java
Minimized windows now receive equal old and new property values. Active resizing now receives different values and continues notifying listeners.

Estimated code review effort: 2 (Simple) | ~10 minutes

Merge Risk: ⚪ Minimal · up to 89e90

This localized rendering fix changes minimize-time framebuffer resize signaling so normal resizes continue to propagate; no actionable merge-blocking risk remains after normal checks and review.

Poem

A rabbit resized the viewport with care,
Kept minimized frames from stirring the air.
When windows grow wide, notifications hop,
FBOs stay steady when minimized clocks stop.
updateViewport now gets it just right.

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly describes the fix that suppresses zero-size FBO resizing during window minimization.
Description check ✅ Passed The description accurately explains the minimization bug, root cause, condition reversal, verification limits, and compilation result.
Linked Issues check ✅ Passed The change addresses [#5081] by suppressing zero-size framebuffer resize events during minimization while preserving normal resize notifications.
Out of Scope Changes check ✅ Passed The changes are limited to the viewport notification condition and directly support the linked issue objective.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch soloturn-fix-minimize-black-screen

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

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

Labels

Type: Bug Issues reporting and PRs fixing problems

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

Game Screen goes dark after minimizing

2 participants