Open daonb opened 1 year ago
Similar ask to https://github.com/xtermjs/xterm.js/issues/4186
Thanks @Tyriar . I realize its an edge case and I'll have to develop it myself. I hope you can help with design and review.
I thought of extending the webgl addon constructor with optionals parameters. I came up with two options:
With the second option the addon will create the off-screen canvas on the first run. In both cases the app will be charged with laying out the terminals on the single canvas, allowing Terminal7 to keep its windows layout.
Which option do you prefer? Is there a better option I missed?
I think the tricky part in trying to build this into xterm.js is coming up with a nice method of creating and sharing the context. The first option seems the most promising imo but I'd need to see more of it to know whether it's good or not. You would also need to way of changing the offset.
With the second option the addon will create the off-screen canvas on the first run.
This won't play nicely with tabs, not all xterm.js instances are necessarily visible at once.
Browsers have a strict limit on the number of active WebGL contexts on a page. Terminal7's multiplexer often needs dozens of panes and the browser does not support it. For example, I have a couple of hosted servers each with 5 tabs with an average of 2.5 panes per tab - that's 25 panes right there and no browser supports that many contexts.
I did a bit of research and found a solution in this SO answer. In a nut shell, it suggests a hidden single ever growing WebGL context for drawing the terminals and using
gl.scissor
andgl.viewPort
to render the visible terminals on the page. I hope the diagram helps explain: