Agree that sharing a single context between canvases seems like a more workable approach than the opposite -- it will lead to less memory overhead (no need to have N OpenGL contexts for N canvases, and no need to rely on OpenGL share groups).
Some random thoughts:
- what happened to the previously discussed idea of an idea like this:
- a big problem with the approach of having to getContext before telling that you want to use another existing context, is that it will force the browser to create a drawing buffer which you may turn out to never use. We need an API that avoids such waste by allowing to avoid creating drawing buffers. The earlier-discussed bindFramebuffer(canvas) proposal, applied to a new canvas that doesn't already have a context on it, was a possible way to solve that problem.
- I have a feeling that allowing multiple sets of context attributes is going to be a headache. If we settle on an API that formally allows specifying different context attribs, I'd at least recommend requiring the all the attributes to agree across all canvases, at least as a first step -- we can always relax that later, but if we allow it from the start, we won't be able to change it anymore.
- Likewise, allowing canvases from different principals is going to be a source of pain, so I'd make it a requirement that canvases sharing a context must be on the same principal.
On 12-10-17 09:04 PM, Gregg Tavares (社用) wrote:
I'd like to pursue this idea further that Florian brought up which is that, for drawing to multiple canvases, rather than share resources across contexts it would be much nicer to just be able to use the same context with multiple canvases. Something like