VtkRemoteView remote interaction returns stale frames unless renderWindow.Render() is called explicitly

[weypro]

Hi,

I may be hitting a bug in the remote rendering path used by VtkRemoteView, and I’d like to confirm whether this is expected behavior or a bug in the current stack.

Environment:

• macOS
• Python 3.13
• trame 3.12.0
• trame-vtk 2.11.7
• vtk 9.6.1

What I expected:

• With VtkRemoteView, browser interactions such as rotate / pan / zoom should update the server-rendered image automatically.
• My understanding from the docs is that remote_view.update() is for when the Python side modifies the scene, not for every browser-side interaction.

What I observe:

• Browser interaction events do reach the server and do change the camera.
• But during remote interaction, the pushed image can remain stale for some motions, especially horizontal rotation.
• If I explicitly call renderWindow.Render() before pushing/updating the image, the frame becomes correct.
• If I bypass the normal path and capture with vtkWindowToImageFilter, the image also reflects the new camera correctly.

Why I suspect this is not just an application-side omission:

• VtkRemoteView.update() seems to call push_image() rather than requiring the app to render manually.
• In the current trame_vtk code path, the interaction / viewport handlers call UpdateEvent, but I don’t see an explicit Render() before image delivery.
• This makes me wonder whether the expected contract is:
  1. application code must explicitly call Render() even for remote interaction updates, or
  2. the remote interaction path should already ensure a fresh render before StillRenderToBuffer() / image push.

Minimal observation:

• camera changes: yes
• renderWindow.Render() before push: image updates correctly
• default remote path: stale frames can be returned
• vtkWindowToImageFilter capture: correct image

Question:
Is explicit renderWindow.Render() expected in the VtkRemoteView remote interaction path, or does this look like a bug/regression in the VTK/trame remote image delivery stack?

[jourdain]

Everything you stated is correct, but we should not need any explicit renderWindow.Render() on interaction.

This is where the Render call is happening.