W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2013

Re: [whatwg] Counterproposal for canvas in workers

From: Rik Cabanier <cabanier@gmail.com>
Date: Thu, 17 Oct 2013 20:52:24 -0700
Message-ID: <CAGN7qDDAdP7-BhLCcXaLsRXsrc=itMb5TFCiQoqSAYL7BQCPug@mail.gmail.com>
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: Justin Novosad <junov@google.com>, "whatwg@whatwg.org" <whatwg@whatwg.org>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:12 UTC