Proposal: updates for Canvas2D API

The current Canvas 2D API was originally proposed in 2013. Since then, a lot of 2D graphics APIs have appeared and changed what developers expect from a good 2D API. This proposal tries to modernize Canvas 2D API, considering current and future usage of Canvas and considering the following:

1. Canvas is the web’s direct mode rendering solution that closely matches traditional programming models. This is a particularly common need for games and full featured apps.

2. A common bottleneck for Canvas2D rendering is how many Javascript functions are needed to render a particular scene. With this in mind, adding more expressive APIs (that allow you to render the same scene with fewer commands) will result in better performance.

3. Modern 2D developers sometimes have to fallback to GL for features that are expected to be available in 2D but currently aren’t supported by Canvas 2D.

4. Modern browsers implement a rich set of rendering features that are currently unavailable to developers. Bridging that gap and giving more power to developers is a good thing.

I’ve started a tentative repository, where I’m collecting explainers of some ideas we have on how to move Canvas2D forward. I’m slowly adding more features, but it would be great to get feedback and eventually move this as a full WICG repository.

Add statistics for how many frames are painted to canvas during captureStream() and by requestFrame() while CanvasCaptureMediaStreamTrack muted is false , enabled is true and readyState is not "ended" (irrespective of what Media Capture and Stream specifications states, as AFAICT getSettings() is not explicitly defined for MediaStreamTrack derived from canvas.captureStream()).

The functionality can be simiar to AudioWorkletNode where currentTime and currentFrame point to the respective values for each until the source CanvasCaptureMediaStreamTrack readyState is "ended" . The values can be stored as properties at the canvas element or at the canvas context object.