CanvasInWorkers - Revision history

Junov at 20:34, 18 August 2016

2016-08-18T20:34:34Z

← Older revision		Revision as of 20:34, 18 August 2016
Line 1:		Line 1:
	'''This proposal has been abandoned. Please refer to the ~~more~~ [[OffscreenCanvas]] proposal.'''		'''This proposal has been abandoned. Please refer to the [[OffscreenCanvas]] proposal.'''

	:''This proposal is trying to solve 2 issues: (1) being able to render to a canvas from a worker and (2) being able to render to multiple canvases using a single rendering context''		:''This proposal is trying to solve 2 issues: (1) being able to render to a canvas from a worker and (2) being able to render to multiple canvases using a single rendering context''

Junov at 20:34, 18 August 2016

2016-08-18T20:34:21Z

← Older revision		Revision as of 20:34, 18 August 2016
Line 1:		Line 1:
			'''This proposal has been abandoned. Please refer to the more [[OffscreenCanvas]] proposal.'''

	:''This proposal is trying to solve 2 issues: (1) being able to render to a canvas from a worker and (2) being able to render to multiple canvases using a single rendering context''		:''This proposal is trying to solve 2 issues: (1) being able to render to a canvas from a worker and (2) being able to render to multiple canvases using a single rendering context''

Gman: add a note about multi-sampled buffers

2013-03-01T04:12:34Z

add a note about multi-sampled buffers

← Older revision		Revision as of 04:12, 1 March 2013
Line 154:		Line 154:
	</pre>		</pre>

	In the new model, a typical animating application will create a minimum of 2 DrawingBuffers (for double buffering so a worker can render to one while the other is passed back to the main thread for compositing) or possibly 3 (for Triple Buffering). If all the DrawingBuffers are antialiased that’s 375meg of VRAM used up immediately.		In the new model, a typical animating application will create a minimum of 2 DrawingBuffers (for double buffering so a worker can render to one while the other is passed back to the main thread for compositing) or possibly 3 (for Triple Buffering). If all the DrawingBuffers are antialiased that’s 375meg of VRAM used up immediately.

	On the other hand, if instead we disallow anti-aliased DrawBuffers and expose GL_ANGLE_framebuffer_blit and GL_ANGLE_framebuffer_multisample as WebGL extensions, then a typical app that wants to support anti-aliasing will create a single multisampled renderbuffer and do its own blit to non-multi-sampled DrawingBuffers. For a triple buffered app that would be 218 meg of VRAM.		On the other hand, if instead we disallow anti-aliased DrawBuffers and expose GL_ANGLE_framebuffer_blit and GL_ANGLE_framebuffer_multisample as WebGL extensions, then a typical app that wants to support anti-aliasing will create a single multisampled renderbuffer and do its own blit to non-multi-sampled DrawingBuffers. For a triple buffered app that would be 218 meg of VRAM.

			Another considered solution is to some how magically share a single multi-sample buffer. In a double buffered app you'd transfer a DrawingBuffer from the work to a the main thread. Since the DrawBuffer is intended to be given to a canvas and since you can't render to the drawing buffer because its context is back in the worker then, at transfer time, you could resolve the multi-sampled buffer. And give that multi-sampled buffer to the next DrawBuffer. Unfortunately that won't work under this design. Nothing prevents the user from transferring the DrawingBuffer from a worker to another thread and back to the worker. It should come back as it started. If it was resolved on transfer it would not come back. Another issue is there's nothing preventing the user from making 3 or 4 DrawingBuffers for a single canvas for triple or quadruple buffering. Since you have no idea what a user is going to use a DrawingBuffer or how they are going to use it there's no easy way for them all to magically share the same multi-sample buffer.

	<br />		<br />

Gman: /* Suggested Solution */ typos

2013-02-08T03:41:32Z

Suggested Solution: typos

← Older revision		Revision as of 03:41, 8 February 2013
Line 49:		Line 49:
	Add 2 functions to `Canvas`. Canvas.transferDrawingBufferToCanvas() and Canvas.copyDrawingBuffer()		Add 2 functions to `Canvas`. Canvas.transferDrawingBufferToCanvas() and Canvas.copyDrawingBuffer()

	Canvas.transferDrawingBufferToCanvas effectively transfers ownership of the DrawingBuffer ~~to the canvas take ownership of the DrawingBuffe~~. The user ~~program~~ is ~~no longer able to use it~~. This similar to how transferring a DrawingBuffer from the main thread to a worker makes the main thread no longer able to use it.		Canvas.transferDrawingBufferToCanvas effectively transfers ownership of the DrawingBuffer. The user's DrawingBuffer is neutered. This similar to how transferring a DrawingBuffer from the main thread to a worker makes the main thread no longer able to use it.

	A single threaded app that wanted to emulate the existing workflow using DrawingBuffers would do something like this.		A single threaded app that wanted to emulate the existing workflow using DrawingBuffers would do something like this.

			<pre>
	var gl = new WebGLRenderingContext();		var gl = new WebGLRenderingContext();
	function render() {		function render() {
Line 61:		Line 62:
	requestAnimationFrame(render);		requestAnimationFrame(render);
	}		}
			</pre>

	Canvas.copyDrawingBuffer() on the other hand copies the DrawingBuffer’s texture/backingstore to the canvas. This is a slower path but emulates the standard Canvas2D persistent backingstore style. The canvas will have to allocate a texture or bucket of pixel to hold the copy if it does not already have one.		Canvas.copyDrawingBuffer() on the other hand copies the DrawingBuffer’s texture/backingstore to the canvas. This is a slower path but emulates the standard Canvas2D persistent backingstore style. The canvas will have to allocate a texture or bucket of pixel to hold the copy if it does not already have one.

Gman: /* My Solution */

2013-02-08T03:38:33Z

My Solution

← Older revision		Revision as of 03:38, 8 February 2013
Line 31:		Line 31:
	One proposed solution involves <tt>CanvasProxy</tt> and a <tt>commit</tt> method. This solution does not meet the goals above. Specifically it does not handle synchronization issues and may waste memory.		One proposed solution involves <tt>CanvasProxy</tt> and a <tt>commit</tt> method. This solution does not meet the goals above. Specifically it does not handle synchronization issues and may waste memory.

	=== My Solution ===		=== Suggested Solution ===
	Allow rendering contexts to be created by constructor		Allow rendering contexts to be created by constructor

Gman: /* Issues: */ formatting

2013-02-08T03:36:30Z

Issues:: formatting

← Older revision		Revision as of 03:36, 8 February 2013
Line 302:		Line 302:
	== Issues: ==		== Issues: ==

	* Workers can flood the graphics system with too much work.		=== Workers can flood the graphics system with too much work. ===

	In the main thread you can write code like this		In the main thread you can write code like this
Line 326:		Line 326:
	Which suggests that even the main thread should not be allowed to render to contexts created by a constructor except in requestAnimationFrame?		Which suggests that even the main thread should not be allowed to render to contexts created by a constructor except in requestAnimationFrame?

	* How should GL_ANGLE_framebuffer_multisample be specified w.r.t. number of samples? (webgl specific)		=== How should GL_ANGLE_framebuffer_multisample be specified w.r.t. number of samples? (webgl specific) ===

	We’d like apps not to fail based on the “samples” parameter to renderbufferStorageMultisample but GL_ANGLE_framebuffer_multisample is specified that it must allocate a renderbuffer with the user specified number of “samples” or greater. That means if an app passes the wrong number in (say hardcodes a 4) and the user’s GPU does not support 4 samples or the user’s GPU multi-sample support is blacklisted the app will fail.		We’d like apps not to fail based on the “samples” parameter to renderbufferStorageMultisample but GL_ANGLE_framebuffer_multisample is specified that it must allocate a renderbuffer with the user specified number of “samples” or greater. That means if an app passes the wrong number in (say hardcodes a 4) and the user’s GPU does not support 4 samples or the user’s GPU multi-sample support is blacklisted the app will fail.

Gman at 22:18, 7 February 2013

2013-02-07T22:18:23Z

Show changes

Hixie: Created page with "blank"

2013-02-07T21:26:57Z

Created page with "blank"

New page

blank