[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] getContext multiple context language



On 2/2/2010 2:25 AM, Mark Callow wrote:
Apologies for my delayed response. I took a week off.

The language is fine up until the last paragraph.

Vladimir Vukicevic wrote:
Here's the language for getContext() -- let me know of any suggestions before I send it off to hixie:
...

If multiple rendering contexts are active, they all render to the same canvas; they are not layered or otherwise isolated.  Changes made to the canvas with one context must be immediately visible to any other active contexts on the canvas.  It is up to the implementation to manage synchronization issues associated with rendering with different contexts to the same canvas.
Implicit synchronization is fraught with problems as I have stated many times before during this discussion. Lack of explicit synchronization is a nightmare for implementers (with the tangled web of checks between contexts growing as each new context type is added) and will encourage developers to interleave calls in ways that will be horrendously inefficient on any hardware that is attempting parallelism, which these days is pretty much everything.

An explicit waitContext(in DOMString contextId) function should be added to the canvas for synchronization between contexts. This would flush commands previously issued to "contextId" and wait for them to complete and would be required between calls to drawing commands of different contexts.

I think the problem is that we're actually trying to really discourage any multiple context rendering, because we don't want to have to specify the details of how that would work right now -- but there's no way to prevent someone from implementing it given the way the canvas context API was designed, so the thinking is that we should have some explicit language in the spec about it, pushing all the complexity to any implementation that's willing to actually try it.  I'd be happy to add language saying that supporting multiple rendering contexts is not recommended, and that a future version of this specification will add explicit synchronization points -- would that help?

    - Vlad