Why do basic classes need to be loaded in genericRenderWindow and fullScreenRenderWindow?

Web
1

Hi,

Please see vtk-js/index.js at master · Kitware/vtk-js · GitHub and vtk-js/index.js at master · Kitware/vtk-js · GitHub. If I remove these imports I still get rendered scene and everything works fine. Why these imports must be explicitly defined? When should I define these imports?

Please also clarify, why vtk.js/Rendering/Profiles/Volume needs to be explicitly imported for rendering? See vtk-js/index.js at master · Kitware/vtk-js · GitHub.

Best regards,
Stas

2

Your points on the imports in the FullScreenRW and GenericRW is correct. They should not be needed. Probably added for an example a while back that was using the vtk() function but definitely not required here. Also if you do those import yourself somewhere else, it would have the same behavior. And won’t increase the bundle size.

For the profiles it is a different story. Those are meant to load the concrete implementation of a given mapper/actor either for WebGL or WebGPU or both so the rendering can happen. Also you don’t need to use profiles, you can just import the classes you intent to use. They will automatically register themselves into the rendering factory. But by design nothing bring them in to allow tree-shaking. That way no need to bundle +100KB of SurfaceLIC if you don’t want to use it…

3

Thank you very much!

Regarding the profiles. I understand that if I don’t use some rendering profiles they shouldn’t be bundled. However, if I import volume/volumeMapper why not import a specific implementation? For example, when I import @kitware/vtk.js/Rendering/Core/VolumeMapper it ideally can load a concrete WebGL or WebGPU or both implementations. Are there any limitations for not doing so?

Best regards,
Stas

4

Yes ideally we would like to do exactly that, but because we can not conditionally import files. We would have to force it to the user. I guess WebGL could be forced today, but ideally we want to give the choice to the user. So Profiles were created to mitigate that part.

The first step was to remove the eager import all that we had before. Now that we have a clean separation that is working we could figure out a better way to make it simpler for the user. Ideally using dynamic import based on a backend(s) variable. But at the time I could not do it with the time I had available.

1 Like