Re: [whatwg] Canvas in workers

On Sun, Oct 13, 2013 at 12:01 PM, David Bruant <bruant.d@gmail.com> wrote:

> Le 13/10/2013 06:12, Kyle Huey a écrit :
>
>      2. Add a worker-only WorkerCanvas constructor that takes the desired
>>     width/height of the drawing surface.
>>
> What is the use case for this constructor? Draw something in worker,
> output an image to be sent to main thread?


When drawing complex stuff to a canvas (e.g. opacity groups) you often need
to create a temporary canvas to hold some subset of the content and then
composite that temporary canvas to the main canvas.


>
>
>      3. Remove the rendering context constructors and the setContext method
>>     on WorkerCanvas (née CanvasProxy).
>>     4. Copy all of the sensible non-node related things from
>>     HTMLCanvasElement to WorkerCanvas.  This would include
>>     - width and height as readonly attributes
>>        - getContext (to replace what we removed in step 3).  roc prefers
>> to
>>        have getContext2D and getContextWebGL, and dispense with the string
>>        argument version entirely, but I don't have strong feelings.
>>
> For the sake of writing interoperable code in main thread and worker, I
> tend to be against this sort of change. I'm aware of the ugliness of some
> APIs, but consistent ugly APIs beats a mix of beautiful and ugly API.


Fine, let's consider that suggestion dropped.


>
>
>         - toBlob.  We do not intend to implement toDataURL here.
>>     5. Add a "commit" method to WorkerCanvas.  For a WorkerCanvas obtained
>>     from a main thread <canvas> element, this would cause the buffer
>> displayed
>>     on screen to swap.  For a WorkerCanvas created *de novo* on a worker
>>     thread, it would do nothing.
>>
> Let's have this method optional, then? Or create 2 interfaces? I'm not
> sure of what can be expressed in WebIDL to solve this, but useless methods
> aren't a good idea. If I can't do anything, don't give me the method. It's
> like in UI. If I can't click a button, just don't show me the button or at
> least grey it out.


We could put it in a separate interface. I'm not sure that's worth it, but
whatever, that's a trivial issue.


>
>>    bool commit();
>>>
>> Boolean as return value for success? :-s
> A promise instead maybe? throw instead of false at least?
> In any case, it looks like commit could be a long operation (tell me if
> I'm wrong here. Do you have numbers on how long it takes/would take?),
> having it async sounds reasonable.


"commit" does not need to be async, it doesn't have to block in practice.

I feel fairly strongly against the run-to-completion violation as it's a
> foundation of how JavaScript works, how people reason about programs. Also,
> TC39 is working hard to close the gap between what can be expressed in pure
> ECMAScript and what the web platform does express, it'd be inappropriate to
> add things that widen this gap in my opinion.
>

Personally I don't see this as a violation of run-to-completion semantics.
The important thing is that the dimensions of the WorkerCanvas (and any
other state observable by the worker) do not change except during the call
to commit(). Effectively commit() itself performs the change. Of course
it's OK for DOM API implementations to change state :-).

Rob
-- 
Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w  *
*

Received on Sunday, 13 October 2013 21:34:16 UTC