[jspanchu]

No description provided.

[ahinoamp]

I would like to use this API for small server-produced changes while keeping transient hover presentation in the browser. Could the tests cover replacing a dependency of the selected object, preserving the client camera and untouched objects, and alternating subset updates with a subsequent full update? A second view sharing the session would also be a useful regression case. Measuring the reduction in serialization work alongside the visible result would make the performance benefit easier to assess.

[jspanchu]

I have resolved a merge conflict and rebased to bring this PR up to date. Will add test to cover this kwarg.

[jspanchu]

Serialization work per update (view1):
step                         roots  serialize (ms)  states sent  blob bytes
subset: replace mapper           1           0.296           17          84
full: replace mapper             2           4.462           17          84
subset: recolor                  1           0.204            2           0
view2 full                       1           0.660           11       84536

as you can see the time to serialize goes down. ~20x faster, however the stuff sent over network is the same for both strategies due to mtime diffing on the client.

[jourdain]

LGTM, but I mostly looked at the main src/trame_vtklocal/widgets/vtklocal.py‎

[jspanchu]

@ahinoamp can you verify the test and it's result is what you expect?

[ahinoamp]

Yes, this covers the cases I had in mind. I reviewed the test and confirmed that it:

• replaces the selected actor mapper and its upstream source through a subset update;
• preserves the client-controlled camera and browser-only hover color;
• keeps an unrelated server edit out of the subset update, then delivers it with the following full update;
• exercises another subset update after the full update; and
• updates a second view in the same session, with pixel comparisons at each stage.

The reported result also matches the mechanism I expected: limiting the roots reduces server-side serialization traversal, while client-side mtime diffing means the changed states and blob bytes sent for the mapper replacement can remain the same. The exact ~20x ratio is run-dependent, but the direction and explanation are right. Linux, macOS, and Windows test jobs are all green. This looks good to me.