Re: [whatwg] Counterproposal for canvas in workers

On Sun, Oct 20, 2013 at 2:22 AM, Robert O'Callahan <robert@ocallahan.org>wrote:

> > On Fri, Oct 18, 2013 at 3:10 PM, Glenn Maynard <glenn@zewt.org> wrote:
>> >>  Also, with the "transferToImageBuffer" approach, if you want to render
>> >> from a worker into multiple canvases in the UI thread, you have to post
>> >> those ImageBuffers over to the main thread each frame, which has the
>> same
>> >> (potential) synchronization issues as the transferDrawingBufferToCanvas
>> >> proposal.
>>
>
I'm confused here. You said "if you want to render from a worker into
> multiple canvases in the UI thread", which I took to mean that you wanted
> to synchronize canvas updates from workers with DOM changes made by the UI
> thread. But now you're saying you don't want to do that. So I don't know
> what you meant.
>

This has nothing to do with synchronizing to DOM updates.  The point is to
be able to render from a single WebGL context to multiple canvanses,
without having to create multiple WebGL contexts and upload a second copy
of textures, vertex programs, etc. into it, which is very expensive.  Doing
that efficiently and asynchronously is what this is trying to solve.  (The
particular problem I pointed out is specific to doing that from Workers
with canvases in the UI thread, but the goal itself is not.)

-- 
Glenn Maynard

Received on Sunday, 20 October 2013 14:11:40 UTC