[Remote rendering 4.4] Live scene refresh upon server-originated operations in remote mode
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 50/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- python
- Domain
- full-stack
Research direction
Start with the server-side operations add_dataset, update_variables, and load_state, then trace the remote-mode client path for scene refreshes. Verify that a Python API scene change updates the rendered frame and the relevant tree, legend, color panel, or widget UI without a browser reload, and run the project tests.
Written by the indexing model from the issue text.
Description
📝 Description of the feature
Fullstack user story. Keep the client view in step with server-side scene changes so adding or removing a dataset on a live remote session refreshes the view without a browser reload.
When a scene-mutating operation originates on the server (ie through an API, eg add_dataset, update_variables, load_state), the client has no way to know unless the server tells it. This user story propagates those changes: the server signals that the scene changed, and the frontend re-fetches scene details and rebuilds so the view reflects the new structure.
Two main surfaces update:
- The rendered frame (the server re-renders it and the stream carries it), and the UI computed from scene structure, tree view, legend/color panel, and widgets, which the frame alone doesn't touch.
- The surfaces differ by operation, most involve a tree rebuild, while update_variables changes variable metadata and so the legend rather than the tree.
Fullstack: the backend signal and frontend rebuild are individually untestable, so these are together in a single user story here.
Acceptance Criteria
A Python API call that modifies the scene, e.g. add_dataset, refreshes without a browser reload, and the corresponding UI updates (e.g. tree rebuild) works in remote mode.
Tests pass
💵 Business Value
No response
🔗 Useful links and references
No response
- Dominant language
- Python
- Stars
- 1
- Forks
- 0
- Avg merge
- 1d 21h
- Merged PRs (30d)
- 47
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from ansys/Visual-Interactive-Simulation-Object-Renderer
-
Difficulty 3/5 1-2 days Newbie friendliness 50/100
-
Library updates Opentechnical
ansys/Visual-Interactive-Simulation-Object-Renderer#136 · 1 assignee ·
-
maintenance
ansys/Visual-Interactive-Simulation-Object-Renderer#131 · 1 assignee ·
-
Release 1.0.2 Openmaintenance
ansys/Visual-Interactive-Simulation-Object-Renderer#130 · 1 assignee ·
-
enhancement
ansys/Visual-Interactive-Simulation-Object-Renderer#126 · 1 assignee ·
All issues in ansys/Visual-Interactive-Simulation-Object-Renderer
Similar issues
-
agent-ready documentation needs-triage
Difficulty 1/5 1-3 hours Newbie friendliness 88/100
-
documentation
Difficulty 1/5 Under an hour Newbie friendliness 91/100
-
workflow-status page template still says reusable workflows are "triggered only by workflow_call:" Open
Difficulty 1/5 Under an hour Newbie friendliness 92/100
-
instance instance add
Difficulty 1/5 Under an hour Newbie friendliness 72/100
searxng/searx-instances#939 · 1 comment ·
-
area-deployment area-integrations triage:bot-seen
Difficulty 2/5 Half a day Newbie friendliness 86/100