fix(gui): land in-flight screen transitions under message boxes and wait screens - #359
fix(gui): land in-flight screen transitions under message boxes and wait screens#359NathanNeurotic wants to merge 1 commit into
Conversation
…ait screens
Error boxes and blocking wait screens (guiMsgBox, guiRenderTextScreen)
draw their background with guiShow(), which during a screen transition
renders the OLD, fading-out screen for the first ~13 frames of the
26-frame fade -- so a box raised right as a transition starts sits on
the previous screen ('error messages always have the previous frame as
their background', zackcage6). Snap any in-flight transition to its
destination before the box's render loop, using the same assignments
guiShow() makes when a fade completes naturally.
Scope note: the other 'wrong background' shape -- a box raised from a
settings flow showing the main screen instead of the dialog behind it --
is deliberately left alone. The deferred error hook (errorMessageHook)
fires after the dialog's setup function has returned and its stack-local
enum arrays have died, so rendering that dialog then would dereference
freed stack (the #154 dangling-enum landmine). A safe version of that
needs the affected dialog enum arrays made static first; separate change
if the transition snap does not fully cover the report.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
📝 WalkthroughWalkthroughThe GUI now completes an active screen transition before it renders a message box or text wait screen. The new helper promotes the transition target to the current screen and cancels the fade. ChangesScreen transition snapping
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/gui.c`:
- Around line 2774-2781: Update guiSnapTransition so that, when
screenHandlerTarget is set and before clearing it, it calls
padFreezeEdgeBaseline(0) to release the pad edge-freeze state. Preserve the
existing handler swap, target reset, and transition-index reset behavior.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 145ef1ff-6014-4734-b024-79cd1457c850
📒 Files selected for processing (1)
src/gui.c
📜 Review details
⏰ Context from checks skipped due to timeout. (20)
- GitHub Check: build-variants (EXTRA_FEATURES=1, PADEMU=1)
- GitHub Check: build-variants-ps2dev-latest (EXTRA_FEATURES=1, PADEMU=1)
- GitHub Check: build-debug-ps2dev-latest (iopcore_ppctty_debug)
- GitHub Check: build-debug (eesio_debug,
@sha256:c64ae69c9817865ed98ff054e4ae5360b9e280ed952c97946bca95d9d35be995) - GitHub Check: build-debug-ps2dev-latest (iopcore_debug)
- GitHub Check: build-debug (ingame_ppctty_debug,
@sha256:c64ae69c9817865ed98ff054e4ae5360b9e280ed952c97946bca95d... - GitHub Check: build-variants-ps2dev-latest (EXTRA_FEATURES=0, PADEMU=1)
- GitHub Check: build-debug (iopcore_debug,
@sha256:c64ae69c9817865ed98ff054e4ae5360b9e280ed952c97946bca95d9d35be... - GitHub Check: build-variants-ps2dev-latest (EXTRA_FEATURES=0, PADEMU=0)
- GitHub Check: build-debug-ps2dev-latest (DTL_T10000=1)
- GitHub Check: build-variants-ps2dev-latest (EXTRA_FEATURES=1, PADEMU=0)
- GitHub Check: build-debug-ps2dev-latest (eesio_debug)
- GitHub Check: build-variants (EXTRA_FEATURES=0, PADEMU=1)
- GitHub Check: build-debug (DTL_T10000=1,
@sha256:c64ae69c9817865ed98ff054e4ae5360b9e280ed952c97946bca95d9d35be995) - GitHub Check: build-debug (iopcore_ppctty_debug,
@sha256:c64ae69c9817865ed98ff054e4ae5360b9e280ed952c97946bca95... - GitHub Check: build-variants (EXTRA_FEATURES=1, PADEMU=0)
- GitHub Check: build
- GitHub Check: build-variants (EXTRA_FEATURES=0, PADEMU=0)
- GitHub Check: build-debug (ingame_debug,
@sha256:c64ae69c9817865ed98ff054e4ae5360b9e280ed952c97946bca95d9d35be995) - GitHub Check: build-ps2dev-latest
🔇 Additional comments (2)
src/gui.c (2)
2926-2933: LGTM!
3067-3070: LGTM!
| static void guiSnapTransition(void) | ||
| { | ||
| if (screenHandlerTarget) { | ||
| screenHandler = screenHandlerTarget; | ||
| screenHandlerTarget = NULL; | ||
| transIndex = 0; | ||
| } | ||
| } |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
rg -n -C 8 \
'\b(guiSnapTransition|screenHandlerTarget|screenHandler|transIndex|padFreezeEdgeBaseline)\b' \
. --glob '*.c' --glob '*.h'Repository: NathanNeurotic/Open-PS2-Loader
Length of output: 15764
🏁 Script executed:
#!/bin/bash
set -euo pipefail
wc -l src/pad.c src/gui.c include/pad.h
sed -n '140,180p' src/pad.c
sed -n '2,30p' include/pad.hRepository: NathanNeurotic/Open-PS2-Loader
Length of output: 2005
Snap also clears the pad edge-freeze state.
guiShow only releases padFreezeEdgeBaseline() in guiReadPads() after screenHandlerTarget is cleared. If guiSnapTransition() occurs mid-transition, guiMsgBox() and guiRenderTextScreen() can start with input frozen on the destination screen. Update padFreezeEdgeBaseline(0) in the snap path while screenHandlerTarget is still set.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/gui.c` around lines 2774 - 2781, Update guiSnapTransition so that, when
screenHandlerTarget is set and before clearing it, it calls
padFreezeEdgeBaseline(0) to release the pad edge-freeze state. Preserve the
existing handler swap, target reset, and transition-index reset behavior.
Addresses zackcage6's repeated report: error/notice message boxes show the previous frame as their background.
Cause
guiMsgBoxandguiRenderTextScreendraw their background withguiShow(), which renders the currentscreenHandler. During a screen transition (the 26-frame cross-fade afterguiSwitchScreen),guiShow()deliberately renders the old, fading-out screen for the first half. So a box raised right as a transition begins — exactly when errors tend to fire (pick a game → transition → launch fails) — sits on the previous screen for ~13 frames.Verified the main screen otherwise repaints its own background every frame (
menuRenderMain→ theme background element), soguiShow()is not itself a stale-frame source outside a transition.Fix
guiSnapTransition()completes any in-flight transition to its destination before the box renders — the same state assignmentsguiShow()makes when a fade finishes naturally. One file, +29 lines. The input-freeze release timing shift it introduces is benign (documented inline; the box consumes its own edge-triggered dismiss).Deliberately out of scope
The other 'wrong background' shape — a box raised from a settings flow rendering the main screen instead of the dialog behind it — is not handled here. I prototyped it (record the active dialog, render it under the box) and adversarial review caught that it reintroduces the #154 dangling-enum landmine: the deferred error hook fires after the dialog's
guiShowXxxsetup returns and its stack-local enum arrays die, so rendering that dialog then dereferences freed stack (confirmed reachable via Network → Reconnect → sync eth re-init failure). A safe version requires making the affected dialog enum arraysstaticfirst — a separate change, only if the transition snap doesn't fully cover the report.Separate from the #340 input work. HW test pending.
🤖 Generated with Claude Code
Summary by CodeRabbit