fix(WidgetManager): cross-renderer widget usage

[floryst]

Context

Widgets should not remain in an active state if interaction occurs outside of the containing renderer.

An alternative to deactivating all widgets in the widget manager in such a scenario is to filter out interaction events at the widget level that are not targeting the widget's renderer. Such an alternative has the benefit of allowing widgets to remain active for future in-renderer interactions.

I'm still figuring out if this change might break any existing expectations.

Addresses #3144.

Results

• Fixes [Bug] InteractiveOrientationWidget stuck in active state #3144, and probably any other widget that operates in a overlapping renderer

Changes

• Fixes to vtkWidgetManager

PR and Code Checklist

• semantic-release commit messages
• Run npm run reformat to have correctly formatted code

Testing

• This change adds or fixes unit tests
• Tested environment:
  • vtk.js:
  • OS:
  • Browser:

[jord1e]

Hi @floryst, this seems to work great

I am getting some weird behaviour with the widget disappearing and my screen zooming out in some situations, but I am 99.99% sure that it is because of my own flawed self-implemented zooming logic.

In general, clicking the widget works as expected, and I'm no longer getting the freezes on Firefox/Windows

Thank you so much, look forward to this being merged if no other issues are encountered

[floryst]

@finetjul what do you think about this approach vs the one I mentioned in the PR description?

[lahdemaki]

Thanks for the suggested fix! Any update on accepting this or some other fix to #3144 @finetjul ?

[finetjul]

@lahdemaki we actually discussed it recently with @floryst. We discussed a slightly different approach. @floryst have you had a chance to work on the approach ?

[floryst]

Update: I have a slightly different approach in the https://github.com/Kitware/vtk-js/tree/add-renderer-change-event branch, which adds a RendererChange event. Whenever a widget detects rendererChange, it deactivates itself.

This approach doesn't work well with the vtkPaintWidget. In the scenario with two renderers, if the mouse leaves the scene the paint widget deactivates, requiring users to re-activate the widget when re-entering the scene.

@finetjul I think a better approach would be to have each of a widget's event handlers filter only on events targeting the associated view widget's renderer. What do you think?

[Antti-Palola]

Has there been any further discussion on this?

[floryst]

I'll pick this back up this week. I'm opting to instead filter events rather than the current implementation, because disabling widgets when changing renderer focus is not ideal.