A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.

To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).

WorkerCanvas: Difference between revisions

From WHATWG Wiki
Jump to navigation Jump to search
(Added use case description)
No edit summary
Line 1: Line 1:
'''This proposal is obsolete.  Please refer to the more up-to-date [[OffscreenCanvas]] proposal.'''
:''Provides more control over how canvases are rendered.''
:''Provides more control over how canvases are rendered.''



Revision as of 20:33, 18 August 2016

This proposal is obsolete. Please refer to the more up-to-date OffscreenCanvas proposal.

Provides more control over how canvases are rendered.

Use Case Description

Feedback from web application authors using canvases have shown the need for the following controls:

  • (From ShaderToy, Sketchfab, Verold): need to be able to render to multiple regions on the page efficiently using a single canvas context. 3D model warehouse sites desire to show multiple live interactive models on the page, but creating multiple WebGL contexts per page is too inefficient. A single context should be able to render to multiple regions on the page.
  • (From Google Maps): need to be able to render WebGL from a worker, transfer the rendered image to the main thread without making any copy of it, and composite it with other HTML on the page, guaranteeing that the updates are all seen in the same rendered frame.
  • (From Mozilla and partners using Emscripten and asm.js): need to be able to render WebGL entirely asynchronously from a worker, displaying the results in a canvas owned by the main thread, without any synchronization with the main thread. In this mode, the entire application runs in the worker. The main thread only receives input events and sends them to the worker for processing.

WebIDL

[Constructor(unsigned long width, unsigned long height)]
interface WorkerCanvas {
  attribute unsigned long width;
  attribute unsigned long height;
  RenderingContext? getContext(DOMString contextId, any... arguments); 
  void toBlob(FileCallback? _callback, optional DOMString type, any... arguments);
  ImageBitmap transferToImageBitmap();
};

WorkerCanvas implements Transferable;
ImageBitmap implements Transferable;

partial interface HTMLCanvasElement {
  WorkerCanvas transferControlToWorker();
};

partial interface ImageBitmap {
  void transferToImage(HTMLImageElement image);
};

Spec changes

Transferring of ImageBitmaps has to be defined. It should neuter the ImageBitmap in the sending thread. Neutering sets the ImageBitmap's width and height to 0.

HTMLCanvasElement.transferControlToWorker behaves like transferControlToProxy in the current WHATWG spec. WorkerCanvas is Transferable, but transfer fails if transferred other than from the main thread to a worker. All its methods throw if not called on a worker, or if it's neutered.

ImageBitmap.transferToImage removes the image element's "src" attribute and makes the image display the contents of the ImageBitmap (until the next transferToImage to that image, or until the image's "src" attribute is set). The ImageBitmap is neutered.