Subviewport render fix

[GeneralProtectionFault]

Fixes #1283

The bug results from an issue handling viewport "siblings" at the same level in a parent-child hierarchy. They were sorted by RID, which causes problems depending on what order they were added to the scene tree, etc...

If the viewport's texture is consumed by a sibling viewport, it needs to be rendered first. or else the sibling can get a stale texture, hence epilepsy flicker texture.

This adds/uses a property to the Viewport struct to track if a viewport's texture is consumed by another.
This gives us the info we need to build a dependency graph, and sort the sibling viewports.

Summary by CodeRabbit

• Bug Fixes
  • Improved viewport rendering order when a viewport consumes another viewport’s texture.
  • Ensured consuming viewports render after the viewports producing their textures.
  • Made dependency tracking frame-accurate to prevent stale ordering decisions.
  • Recalculated ordering automatically when a viewport’s parent changes.
  • Added cycle safeguards to preserve a stable render order when dependencies loop.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 92bb8796-f40c-4f6f-bae9-d004bcc68088

📥 Commits

Reviewing files that changed from the base of the PR and between 68f2512 and 0d561c6.

📒 Files selected for processing (2)

• servers/rendering/renderer_viewport.cpp
• servers/rendering/renderer_viewport.h

🚧 Files skipped from review as they are similar to previous changes (2)

• servers/rendering/renderer_viewport.cpp
• servers/rendering/renderer_viewport.h

---

Walkthrough

Viewport rendering now records sibling texture-consumption dependencies each frame, topologically orders sibling viewports so consumers render before producers, falls back on cycles, and invalidates ordering when parent relationships change.

Changes

Viewport dependency ordering

Layer / File(s)	Summary
Dependency-aware sibling sorting servers/rendering/renderer_viewport.h, servers/rendering/renderer_viewport.cpp	Adds used_by_viewport tracking and a topological sibling sort used by _sort_active_viewports(), with fallback to the original order when cycles are detected.
Frame dependency capture servers/rendering/renderer_viewport.cpp	Clears stale dependencies, snapshots render-target usage before rendering, records newly consumed sibling targets, and marks ordering dirty after parent changes.

Estimated code review effort: 4 (Complex) | ~45 minutes

Sequence Diagram(s)

sequenceDiagram
  participant RendererViewport
  participant ViewportRenderTargets
  participant ActiveViewportSorter
  RendererViewport->>ViewportRenderTargets: Snapshot render_target_was_used()
  RendererViewport->>ViewportRenderTargets: Render current viewport
  ViewportRenderTargets-->>RendererViewport: Report newly used sibling targets
  RendererViewport->>RendererViewport: Update used_by_viewport
  RendererViewport->>ActiveViewportSorter: Mark sorted ordering dirty
  ActiveViewportSorter->>ActiveViewportSorter: Topologically sort sibling viewports

Loading

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Title check	❓ Inconclusive	The title is related to the change, but it is too vague to explain the specific viewport ordering fix.	Rename it to describe the main fix, e.g. "Fix subviewport sibling render ordering to prevent texture flicker".

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Linked Issues check	✅ Passed	The change addresses #1283 by ordering sibling subviewports so texture producers render before consumers, matching the flicker fix.
Out of Scope Changes check	✅ Passed	The changes stay within subviewport sibling ordering and render-dependency tracking; no unrelated functionality appears to be added.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[Shakai-Dev]

Fix LGTM, just needs testing to see if it works

[GeneralProtectionFault]

Fix LGTM, just needs testing to see if it works

Wow, quick on the trigger :). I did provide a test build to https://github.com/Flashfyre and he said it was working for him. It's probably worth checking in with him to see if that's still the case tomorrow.

[GeneralProtectionFault]

Just checked with Sam, he wasn't able to reproduce the bug on the test build, think we're in good shape.

[Shakai-Dev]

Tested by the author of the issue & myself, lgtm.

[Shakai-Dev]

Codewise LGTM but I think it's a good idea to test it again

[GeneralProtectionFault]

Codewise LGTM but I think it's a good idea to test it again

Sam already confirmed last night that the new bug is only in a specific circumstance, and that the random one was fixed by this change, and also that the new bug still appears on both the fixed, and currently released versions. I don't think there's a regression on that front.

[Shakai-Dev]

LGTM