Platform/GFX/CanvasThingsWeDontPlanToSupport

From MozillaWiki
< Platform‎ | GFX
Jump to: navigation, search

This page tracks things in the HTML spec around the Canvas element and the 2D context that we don't plan to support as currently specced.

probablySupportsContext

probablySupportsContext is under-specified and non-testable in ways that can't be fixed. It is meant to enable an application startup model like the following, which has the advantage of allowing to start downloading assets without waiting for the possibly long getContext() call to return:

 var webglContext = null;
 if (canvas.probablySupportsContext("webgl")) {
   StartDownloadingWebGLAssets();
   webglContext = canvas.getContext("webgl");
 }
 if (!webglContext) {
   StartDownloadingNonWebGLAssets();
 }

However, this introduces a new worst case, where probablySupportsContext succeeds and getContext fails. That case is doubly bad: it is inherently slowest as the most downloads are started, and it is inherently the most unusual that will be the least tested/expected by application developers. Meanwhile, what we can do today with just getContext isn't too bad:

 var webglContext = canvas.getContext("webgl");
 if (webglContext) {
   StartDownloadingWebGLAssets();
 } else {
   StartDownloadingNonWebGLAssets();
 }

This may look bad as the download of assets doesn't start until getContext returns, but in practice, most applications have common assets shared between their different rendering paths (e.g. sound files, game logic, player data, ...) which they can start downloading before the getContext call, so that that time isn't wasted, as even in the worst cases getContext is not slow enough (say the worst case is about 200 ms for the first WebGL context creation in a session, as it needs to cold-load shared libraries... subsequent context creations take less than 5 ms) to be comparable to the time to download typical game assets (several seconds).

So the vague benefits of probablySupportsContext don't seem worth the mess.

Paths API

http://blogs.adobe.com/webplatform/2013/01/31/revised-canvas-paths/

One problem we have is that Paths are created independently of the canvas and we don't support moving path objects between different Graphics Backends.

Canvas proxies / canvas on worker threads

FILL ME (IIUC we do plan to support canvas on worker threads, but not with the "proxies"-based API that's currently in the spec)