[whatwg] Counterproposal for canvas in workers
cabanier at gmail.com
Thu Oct 17 20:48:17 PDT 2013
On Thu, Oct 17, 2013 at 4:32 PM, Glenn Maynard <glenn at zewt.org> wrote:
> On Thu, Oct 17, 2013 at 5:14 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>> Compositors are often already threaded, so synchronizing a buffer flip
>>> with the compositor doesn't seem too far out there.)
>> This proposal implies an extra buffer for the 2d context. My proposal
>> doesn't require that so it's more memory efficient + you can draw in
> You always need at least two buffers: a back-buffer for drawing and a
> front-buffer for display (compositing). Otherwise, as soon as you start
> drawing the next frame, the old frame is gone, so you won't be able to
> recomposite (on reflow, CSS filter changes, etc). Double-buffering at a
> minimum is pretty standard, even for native applications (with none of this
> Web complexity in the way).
Won't you need another front-buffer for the worker to draw to?
> I think WorkerCanvas (as well as CanvasProxy that's in the spec
> today--this isn't new to WorkerCanvas) allows full parallelism in drawing,
> both between the script and the GPU and between the worker and the main UI
>> I don't remember "multiple workers accessing the same canvas" and I'm
>>> not quite sure what it means. I do remember "a single (WebGL) context
>>> rendering to multiple canvases". Is that what you're thinking of?
>> I went back over the history and that was indeed his use case.
> That's a good use case, I've wanted to do that myself. We haven't tried
> very hard to fit it into the WorkerCanvas approach yet, and it may also be
> that the best way to do that is orthogonal to the whole "canvas in workers"
> use case.
> The obvious approach is to add a new method on the context,
> "attachToCanvas(Canvas or WorkerCanvas)", which would just take the context
> and cause its output to be directed to a new Canvas (or WorkerCanvas),
> probably clearing the contents of the new canvas as a side-effect. (This
> could be added to both CanvasRenderingContext2D and WebGLRenderingContext,
> though I suspect this is only really useful for WebGL. There's no
> expensive resource loading with 2d canvas.)
> var canvas = document.querySelector(".canvas1");
> var gl = canvas.getContext("webgl");
> var canvas2 = document.querySelector(".canvas2");
> drawStuff(gl); // don't need to loadExpensiveResources again
> I think that's by far the most straightforward approach for users. Maybe
> there are implementation issues that make this hard, but if so I think they
> would apply to every approach to this use case (they're really all
> different interfaces to the same functionality)...
> Glenn Maynard
More information about the whatwg