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 one viewport uses another viewport’s texture.
  • Ensured dependent viewports render after the viewports producing their textures.
  • Updated ordering when viewport parenting changes.
  • Added safeguards to preserve stable rendering order when circular dependencies occur.

[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: 36863a25-e475-4a22-b106-62a5658ee769

📥 Commits

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

📒 Files selected for processing (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 | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title is concise and clearly points to a subviewport rendering fix.
Linked Issues check	✅ Passed	The changes address the reported sibling subviewport flicker by fixing render order and dependency tracking.
Out of Scope Changes check	✅ Passed	The diff stays focused on viewport ordering and dependency handling with no clear unrelated changes.
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.