[Remote rendering 5.1] pvserver connectivity spike

Aperta

#33 aperta il 25/8/2026 0 commenti 0 reazioni 1 assegnatario Vedi su GitHub

@ansBAkula ci sta già lavorando.

Dal 11/9/2026.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

research

📝 Description of the feature

pvserver is a separate rendering process you connect to as a client, replacing the in-render window the spike used. This story is a timeboxed investigation to find out what integrating it actually takes, before committing to the implementation in 5.2. Backend-only. Open questions to answer:

How does RemoteRenderer connect to a pvserver process, and does the existing trame-rca streaming path still work unchanged once it does?
What happens to the session lifecycle now that rendering is in another process?
Do the per-part mutation triggers and VtkNodePipeline still work when the VTK objects live in pvserver's process rather than ours, or do they need to be marshaled across the boundary?
Does interaction (the interactor path, including the 4.5 workaround) change with pvserver in the loop?
Does any state, camera, per-part, need to be serialized/synced across the boundary that was previously just set directly?
How is pvserver packaged into the deployment environment?

Acceptance Criteria

A findings doc answering the above, enough to scope 5.2, including any gaps we didn't account for in Phase 4

💵 Business Value

No response

🔗 Useful links and references

No response

Lingua principale: Python
Stelle: 1
Fork: 0
Merge medio: 1g 21h
PR unite (30g): 46

Guida per i contributori

Apri la guida per i contributori

Come iniziare

Leggi tutta la issue e poi la guida ai contributi del progetto.
Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
Fai un fork del repository e lavora su un branch.
Apri una pull request che faccia riferimento al numero della issue.