and execute it multiple times for different container objects. Doing that too many times (20 AFAIR) results in the following warning and some of the canvases not being rendered. In the console I get:
Too many active WebGL contexts. Oldest context will be lost.
It seems that each vtkRenderWindow creates a new context. Is there a way around it in vtk.js?
This is related to “How many canvas (with 3D context)” are on 1 page. This is a browser limitation. The only way to solve that issue is by making a screenshot and recycling your canvas (or deleting them) for 3D inside your page.
function exitCurrentRenderer(e) {
interactor.setCurrentRenderer(null);
interact_style.setEnabled(false);
}
otherwise the last render window had the interaction active even after the mouse pointer left it (The issue is visible in the official example too vtk.js)
On the cosmetic side, scrolling through the webpage results in “jumps” of the rendering areas. As if the events are handled in a slightly wrong order. Would you have any pointers on how to improve this?
Yes I’ve noticed that issue too. But I guess your solution is working as expect. Or is there something else to add to it? I guess this is for me to fix/improve the current example.
I don’t see the jumps when I tried it on Chrome and Safari. Can you provide some background on which system you’ve noticed those jumps?
Otherwise your doc looks awesome. You may want to re-adjust the center of rotation for some of the pieces so the rotation looks better.
(1) it works but is quirky with manipulators using modifier keys (e.g. shift). I guess it a matter of coding more logic in the event handler.
(2) I noticed it with the official example and the docs above on firefox 89 on Ubuntu 18.04. It does not manifest itself in the three or twgl example. Should I maybe try adding a scroll event handler that forces rerender at the very beginning of the code?
indeed manipulator where meant to always thinking that a renderer/camera should be resolved when you are in a RenderWindow (which is always the case here). That logic is “wrong” for our use case here. I did a change a while back that should allow a better resolution by providing an additional argument to the event so a better decision could be made but additional code would be required to make that smooth. I doubt I will have time to look into it anytime soon. Maybe ping me in two month if I didn’t get to it.
See if you can debug it yourself. Otherwise I’ll try to see if I can reproduce and solve it. For me on Chrome/Safari, things seems to be smooth.
