Re: [whatwg] Canvas in workers

On Sun, Oct 13, 2013 at 11:22 AM, David Bruant <bruant.d@gmail.com> wrote:

>      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.
>>>
>>
>> This should be synchronous and never block.
>>
> I might have misused the word "async" again, sorry about that. I think we
> agree.


Sorry, I also stated this imprecisely ("block" is somewhat overloaded).
Specifically, this function never has to sit around and wait for the
corresponding Canvas thread to become available; it can perform the flip
while the other thread is working.  And if it really did need to
block--we're in a worker anyway, so that's OK.


>  Even if the Canvas is in a
>> different process, it should be possible to do this with IPC without
>> waiting for the other side to process the change.
>>
> How does a worker know when the changes on the screen happened? I imagine
> a worker would want to know that before performing other changes to the
> canvas.
>

If the Canvas wants to change its size, then it should ask the owner of the
WorkerCanvas to make the change, which means the canvas size will never
change while the worker is drawing.  The WorkerCanvas would never change
size while the worker is rendering, and it would know that the canvas
changed size when it receives an onresize event.


On Sun, Oct 13, 2013 at 4:42 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> >    1. Rename CanvasProxy to WorkerCanvas and only allow it to be
>> >    transferred to workers.  I don't think we're interested in supporting
>> >    cross-origin <canvas> via CanvasProxy (I would be curious to hear
>> more
>> >    about what the use cases are).
>>
>

>
> Basically it's simpler to have CanvasProxy/WorkerCanvas only supported on
> workers. Cross-origin isn't itself a concern.
>

I think restricting this to workers is fine.

A simple way is for calls to any methods throw an exception if you're not
in a worker.  This keeps structured clone and transfer simple: the rules
for passing it around are the same as anything else, you just can't use it
if you're not a Worker.  If
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23358 is implemented, that'd
give an easy way to define this.



>     2. Add a worker-only WorkerCanvas constructor that takes the desired
>> >    width/height of the drawing surface.
>> >
>>
>> This looks like it's trying to allow entirely off-screen rendering within
>> a
>> Worker, which is fine, but there's no way to resize the backing store in
>> this mode.
>>
>
> We don't have a use-case for resizing the backing store of a
> worker-created canvas.
>

I suspect this will come up with WebGL, since recreating the context from
scratch can be a lot more expensive there.  We should at least make sure
this is possible later.

Actually, there is a way: change the width and height on the
CanvasRenderingContext2D you get from getContext, which isn't readonly.
I'm guessing that would actually want to be read-only in this proposal,
since it allows making changes that are visible to scripts in the UI thread.


> There is the slight problem that changing both width and height would fire
> two events.
>

Changes to width and height should probably only be applied when the script
returns to its event loop.


> A bigger problem is that your approach isn't compatible with a worker that
> draws frames in a loop without yielding. I'm uncertain how important that
> is, so I'll wait for Kyle to address that.
>

OK.  What are the use cases for doing that?  Being able to do complex work
in a worker in a linear, non-event-based manner is an important use case
for workers in general, but I can't think of any way this applies to
drawing successive frames to a canvas.

-- 
Glenn Maynard

Received on Sunday, 13 October 2013 23:56:43 UTC