multiple canvases - Too many active WebGL contexts. Oldest context will be lost.

Hi all,

I’m trying to display multiple canvases on one page (the specific use case is: CadQuery Examples — CadQuery Documentation). I use the following naive approach:

const openglRenderWindow = vtk.Rendering.OpenGL.vtkRenderWindow.newInstance();
renderWindow.addView(openglRenderWindow);
openglRenderWindow.setContainer(container);

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?

Thanks,
Adam

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.

Thanks! Would implementing this kind of solution three.js webgl - multiple elements or twgl.js - item list be feasible/reasonably easy in vtk.js?

We will have to investigate… Could you create an issue in vtk.js with the link you provided as reference to threejs?

Done, Support for context sharing for multiple canvases · Issue #1940 · Kitware/vtk-js · GitHub .

1 Like

Saw it thanks!

The solution is here: vtk.js

1 Like

Here is what I have so far: CadQuery Examples — CadQuery Documentation

It is 99% there. I have two questions:

  1. I had to use
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)

  1. 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?

Thanks,
Adam

  1. 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.

  2. 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.

Thanks,

(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?

Best,
Adam

  1. 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.

  2. 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.

Regarding (2) I could observe similar behavior (though less severe) on chromium. Here is a screen
image
And a profiling trace for this particular frame.

This is way beyond my js non-skills. If there is no simple/obvious fix, I’ll just use the current code as-is.

it looks like if we can avoid that GC we could be good.