Context creation via getContext can take some time, depending on the operating system, drivers, and so on.Â Pages may create lots of small WebGL contexts to composit into a larger page.Â This can take enough time to perceptibly slow page loads.Â I'd propose the following, which is a very small tweak to the proposal in the "Canvas.getContext error handling" thread [1]:

canvas.addEventListener("webglcontextrestored", initWebGL, false);
canvas.addEventListener("webglcontextlost", webGLError, false);webglcontextrestored or webglcontextlost would be fired from the event loop (not from getContext), indicating that initialization succeeded or failed.Â The context would initially be lost.

This is natural to _javascript_ developers, following the callback mechanism used by other async APIs like XHR and FileReader.Â Note that browsers wouldn't be required to actually initialize contexts
in a thread; only the API semantics would actually be required.

This also encourages an initialization pattern where handling context loss is straightforward.Â Currently, people tend to first write code without considering context loss, and need to refactor later to support it, which often is simply
never done.Â Context restoration would still need to be tested by developers, of course, but the likelihood of it just working is much higher.

(For those not familiar with DOM Events and the event loop, note that in the above sample code, it's guaranteed safe to call addEventListener after calling getContext.Â Those events are fired from a queued task, which won't run until the user code returns to the event loop.Â This mechanism is used by all modern web APIs.)