Re: [whatwg] Synchronizing Canvas updates in a worker to DOM changes in the UI thread

>
> On Tue, Oct 22, 2013 at 2:48 AM, Robert O'Callahan <robert@ocallahan.org
> >wrote:
>
>>
>> > This code actually does something potentially useful which can't easily
>> be
>> > done with attachToCanvas: generating a series of images as fast as
>> possible
>> > which will be processed on another thread in some way other than just
>> > rendering them on the screen. (E.g., be encoded into an animated image
>> or
>> > video file.)
>>
>
(Err, wait.  A few issues come to mind.  1: You can already say
createImageBitmap(canvas) to create an ImageBitmap, which handles the
"store a snapshot of a frame" use cases.  2: If the reason to have a
"transfer" version for these use cases is just an optimization, then it's
not obvious that it's a useful optimization.  The use cases you mention
suggest a GPU readback anyway.  3: If you're doing the encoding yourself in
script, you want ImageData anyway, not ImageBitmap.  I don't object as such
to adding such a method if it's useful, and I don't think I have the energy
right now to debate these in much depth, but this feels like taking a
proposal and searching for uses for it.)


On Tue, Oct 22, 2013 at 12:20 PM, Kenneth Russell <kbr@google.com> wrote:

> On Tue, Oct 22, 2013 at 7:37 AM, Glenn Maynard <glenn@zewt.org> wrote:
> > I just noticed that Canvas already has a Canvas.setContext() method
>
> That's there in support of CanvasProxy, which is a flawed API and
> which this entire discussion is aiming to rectify.
>

I don't see flaws with the setContext() API, which appears to have already
solved the problem of being able to make one context render to multiple
canvases.  Any relation to CanvasProxy isn't relevant to this.



>  > , which
> > seems to do exactly what I'm proposing, even down to clearing the
> backbuffer
> > on attach.  The only difference is that it lives on Canvas instead of the
> > context--the only reason I put it there in my proposal was because this
> only
> > seemed useful for WebGL.  Given that, I think this proposal can be
> > simplified down to just: "put setContext on WorkerCanvas too".
>
> Also, adding a present() method to Canvas.
>

That's mixing up proposals, actually.  Adding present() is for the
"explicitpresent" proposal, which aims at solving the "synchronizing
rendering in a worker to DOM changes in the main thread" use cases.
Reusing setContext() replaces my attachToCanvas() proposal, which is for
the "one context rendering to multiple canvases)" use cases.  They're
orthogonal, not mutually exclusive, and solve different problems.  (We're
mixing up proposals because we're trying to solve too many problems
simultaneously, which is one reason I've tried to split this stuff into
smaller chunks.)


> At a high level I prefer the form of the WorkerCanvas API, including
> transferToImageBitmap and the ability to transfer an ImageBitmap into
> an HTMLImageElement for viewing, and removing the CanvasProxy concept
> and associated APIs. I'd like to focus my own efforts in writing a
> full draft for WorkerCanvas under
> http://wiki.whatwg.org/wiki/Category:Proposals .
>

Again, this is a supplement to WorkerCanvas, not a replacement for it.  (It
may be compatible with CanvasProxy too, but I haven't looked at it closely
to see.)

We're circling around: you keep saying we should use transferToImageBitmap,
I keep pointing out the problems with it that my proposal solves, and you
reply by saying "we should use transferToImageBitmap", without addressing
those problems.  I don't think we have any more information to bring to the
discussion right now, so I think we're at a good point to wait for Hixie to
get around to these threads rather than going over the same stuff again
(and giving him more reading material :).  Here's a summary of my proposal:

- The WorkerCanvas adjustments to CanvasProxy (minus the
transferToImageBitmap stuff), to better address the "rendering to a Canvas
from a worker" and "creating off-screen Canvases in a worker"-related use
cases.
- Include setContext() on WorkerCanvas, to support rendering from one
context to multiple canvases when in a worker.
- Add "explicitpresent" and present() to Canvas, to support synchronizing
rendering in a worker to DOM changes in the main thread without forcing
that synchronization on everybody.

The second and third are independent and can be implemented separately,
after WorkerCanvas itself has time to settle.

-- 
Glenn Maynard

Received on Wednesday, 23 October 2013 00:36:58 UTC