Reporting a set of VTK object types that do not survive vtkObjectManager serialization to the wasm client, as suggested by @jourdain in Zanskar-Geothermal/lanius_viewer#174.
Context. We run a trame application (geothermal subsurface viewer) whose default render mode is client-GPU WASM via trame-vtklocal, with server-side rendering as the fallback. Over about a year we've accumulated a list of object types that render correctly server-side and produce a silent black canvas or a missing actor in local/WASM mode.
The common failure signature is what makes these expensive: no exception, no console error, no warning — the server believes it pushed a complete scene, and the client simply renders nothing (or renders everything except that actor). Each one cost us hours to a few days to isolate, because the natural debugging instinct is to suspect your own geometry or state plumbing.
Types we've found don't survive
| type |
observed |
vtkLODActor |
actor absent client-side; scene otherwise renders |
| decimated LOD mappers |
same |
vtkLegendScaleActor |
absent |
| 2D annotation actors generally |
absent |
vtkDataSetMapper |
black canvas; we now always extract a surface explicitly instead |
What would have helped most
Not necessarily support for these types — several are reasonable things not to serialize. A diagnostic would have saved nearly all of the debugging time: if vtkObjectManager (or trame-vtklocal on top of it) could report "object X of type Y produced no serializable state" or "these state ids are dangling", each of these would have been a five-minute fix rather than a multi-day hunt.
The asymmetry is the problem: the same scene renders correctly through the server-side path, so there's no local signal that anything is wrong. A warning at push time, even behind a debug flag, would turn a silent class of failure into a loud one.
Environment
- VTK
9.6.20260517.dev0 (the wasm-capable nightly from wheels.vtk.org) for the WASM path; vtk==9.6.2 for the server-side path
trame-vtklocal 1.1.0, trame-server 3.13.0, trame-common 1.2.6- Chromium, macOS and Linux (Cloud Run)
Happy to produce a minimal reproducer for any of these individually if that's useful — just say which are worth the effort. I appreciate that "these don't serialize" may partly be by design; the diagnostic ask is the part I'd advocate for regardless.
Reporting a set of VTK object types that do not survive
vtkObjectManagerserialization to the wasm client, as suggested by @jourdain in Zanskar-Geothermal/lanius_viewer#174.Context. We run a trame application (geothermal subsurface viewer) whose default render mode is client-GPU WASM via
trame-vtklocal, with server-side rendering as the fallback. Over about a year we've accumulated a list of object types that render correctly server-side and produce a silent black canvas or a missing actor in local/WASM mode.The common failure signature is what makes these expensive: no exception, no console error, no warning — the server believes it pushed a complete scene, and the client simply renders nothing (or renders everything except that actor). Each one cost us hours to a few days to isolate, because the natural debugging instinct is to suspect your own geometry or state plumbing.
Types we've found don't survive
vtkLODActorvtkLegendScaleActorvtkDataSetMapperWhat would have helped most
Not necessarily support for these types — several are reasonable things not to serialize. A diagnostic would have saved nearly all of the debugging time: if
vtkObjectManager(ortrame-vtklocalon top of it) could report "object X of type Y produced no serializable state" or "these state ids are dangling", each of these would have been a five-minute fix rather than a multi-day hunt.The asymmetry is the problem: the same scene renders correctly through the server-side path, so there's no local signal that anything is wrong. A warning at push time, even behind a debug flag, would turn a silent class of failure into a loud one.
Environment
9.6.20260517.dev0(the wasm-capable nightly from wheels.vtk.org) for the WASM path;vtk==9.6.2for the server-side pathtrame-vtklocal1.1.0,trame-server3.13.0,trame-common1.2.6Happy to produce a minimal reproducer for any of these individually if that's useful — just say which are worth the effort. I appreciate that "these don't serialize" may partly be by design; the diagnostic ask is the part I'd advocate for regardless.