Open jhrmnn opened 8 years ago
The single renderer approach makes sense to me, and seems to be an easy upgrade if the renderer can change DOM elements.
Out of curiosity, how many instances do you have running when this occurs?
About 30, each with hundreds of atoms (not sure whether that matters). I was a bit surprised, didn't seem like a crazy number.
After some testing, it looks like the renderer can't be shared across different canvases, ie. everything rendered has to be in the <canvas>
div.
I'll leave the issue open in case another solution comes up, but won't be able to fix this any time soon.
Do you have an idea what refactoring would be needed? I might try doing it myself.
In my testing, I made a global imoleculeRenderer
variable, replaced this line with:
if (imoleculeRenderer === undefined) {
imoleculeRenderer = new THREE.WebGLRenderer({antialias: true, alpha: true});
and then swapped out instances of this.renderer
and self.renderer
with imoleculeRenderer
. This broke previous canvases, which makes sense.
Regarding whether or not there's a right way to do this, I honestly don't know. The one-renderer approach works if everything is on one canvas, but I don't think that's feasible in a notebook. Maybe there's a smart way to swap out active webGL canvases with static images?
@azag0 @patrickfuller Same problem here. Did you guys figure out any workarounds?
Nothing straightforward unfortunately, at least within the constraints of the jupyter notebook.
I've noticed that in a notebook with many imolecule output cells, both Safari and Chrome fail to render all the cells, some of them throw the following error:
I've also noticed that when I develop a notebook and create a lot of imolecule output cells, the browser eventually starts throwing
I've found that this may be solved by keeping only a single renderer for different scene, but I don't know whether it would be possible to keep a single shared rendered for all imolecule outputs.