Re: [whatwg] Counterproposal for canvas in workers

On Thu, Oct 17, 2013 at 8:21 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Fri, Oct 18, 2013 at 4:10 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>
>> They would still have to wait for each other so the images are composited
>> in-order. If you don't care about that, the 'synchronized' option would
>> let
>> you draw as soon as you exit the task (which is how Chrome always draws
>> since it's faster)
>>
>
> What do you mean "wait for each other"? You only have to wait until
> they're all finished. The cost of actually compositing the images is low.
>

That is true. This would only work for regular source-over operations. If
certain compositing operations are used, they will display incorrectly.


>
>  In fact, an implementation could choose to take the deferred-drawing
>> > approach instead. You would queue up drawing commands in the
>> WorkerCanvas
>> > (or the drawing context), and then transferToImageBitmap would not
>> > immediately render but produce an ImageBitmap implementation
>> encapsulating
>> > the list of drawing commands to be drawn later, wherever/whenever that
>> > ImageBitmap ended up being used. I think for commit() the implementation
>> > would always want to force rasterization on the worker (or possibly some
>> > dedicated canvas-rendering thread); you could forward a list of drawing
>> > commands to the compositor thread for rasterization but I don't think
>> > there's any reason to do that (and some good reasons not to).
>> >
>>
>> Can you tell me how you can ensure that you don't do too much work?
>> Drawing
>> in a continuous loop using 'Commit' would waste a lot of resources.
>>
>
> How to throttle drawing of frames using "commit()" is a completely
> separate issue. Any API that allows direct publishing of frames from
> workers to the compositor will have to deal with it, in roughly the same
> way.
>

Wouldn't it be good to solve that at the same time?

Received on Friday, 18 October 2013 03:52:51 UTC