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

On Mon, Oct 21, 2013 at 4:34 PM, Glenn Maynard <glenn@zewt.org> wrote:
> On Mon, Oct 21, 2013 at 6:08 PM, Kenneth Russell <kbr@google.com> wrote:
>>
>> > Using ImageBitmap for this has a lot of issues.  It requires
>> > synchronizing
>> > with scripts in the UI thread.
>>
>> This isn't difficult, and amounts to a few additional lines of code in
>> the main thread's onmessage handler.
>
>
> Synchronization with the UI thread isn't bad because it's difficult.
> Avoiding synchronization with the main thread has been raised as a desirable
> goal:
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Oct/0152.html
> "including that it isn't possible to render from a worker without
> synchronizing with the main thread."
>
> (My previous comments on this are here:
> http://www.mail-archive.com/whatwg@lists.whatwg.org/msg35959.html)
>
>>
>> The ImageBitmap style proposal has another significant advantage in
>> that it allows a single canvas context to present results in multiple
>> output regions on the page.
>
>
> You can do that.  You just create a WorkerCanvas for each canvas you want to
> present to, hand them to the worker, then attachToCanvas in the worker to
> switch from canvas to canvas.  (That's orthogonal to explicitpresent.)

OK, I misunderstood that part of your attachToCanvas proposal.

There are some unexpected consequences of the attachToCanvas API
style. For example, what if two contexts use attachToCanvas to target
the same canvas? What if one of those contexts is 2D and the other is
WebGL? Currently it's illegal to try to fetch two different context
types for a single Canvas. The current CanvasProxy spec contains
several complex rules for these cases, and they're not easy to
understand.

Will it be guaranteed that if you have a WebGL context, attachToCanvas
to canvas1, do some rendering, and then attachToCanvas to canvas2,
that the only remaining buffer in canvas1 is its color buffer? No
depth buffers, multisample buffers, etc. will have to remain for some
reason?

How would WebGL's preserveDrawingBuffer attribute, which is a property
of the context, interact with directing its output to multiple
canvases?

Fundamentally I think the behavior is easier to spec, and the
implementation is easier to make correct, if the ultimate destination
is an image rather than a canvas, and the color buffer is transferred
out of the WorkerCanvas in an explicit step.

-Ken


>>
>> This sort of resource exhaustion is certainly possible, but I view
>> this downside as smaller than the upside of addressing both of the
>> above use cases.
>
>
> I can only find one thing above that you might be referring to as a use case
> (the one I replied to immediately above).  What was the other?
>
> --
> Glenn Maynard
>

Received on Tuesday, 22 October 2013 02:03:44 UTC