[whatwg] Offscreen canvas (or canvas for web workers).

[David Levin]

On Mon, Feb 22, 2010 at 11:57 AM, Drew Wilson <atwilson at google.com> wrote:

> Do we feel that text APIs are, in general, difficult to implement in a
> multi-thread safe manner?
>

On Mon, Feb 22, 2010 at 11:51 AM, Michael Nordman <michaeln at google.com>
 wrote:

> The lack of support for text drawing in the worker context seems like a
> short sighted mistake.
>

On Mon, Feb 22, 2010 at 2:35 PM, Jeremy Orlow <jorlow at chromium.org> wrote:

> It does indeed seem pretty short sighted.


On Mon, Feb 22, 2010 at 2:48 PM, Maciej Stachowiak <mjs at apple.com> wrote:

> 1) Like others, I would recommend not omitting the text APIs. I can see why
> they are a bit trickier to implement than the others, but I don't see a
> fundamental barrier.
>

I did want to add the text apis but it does add implementation difficulties
for WebKit (and as I understand Firefox). However, they are part of what
people want and it does simplify the interfaces, so done.


On Mon, Feb 22, 2010 at 2:48 PM, Maciej Stachowiak <mjs at apple.com> wrote:

> 2) I would propose adding createPattern and drawImage overloads that take
> an OffscreenCanvas. The other overloads would in practice not be usefully
> callable in the worker case since you couldn't get an image, canvas or video
> element.
>
> 3) This would leave the only difference between the two interfaces as the
> drawFocusRing method. This would not be usefully callable in a worker, since
> there would be no way to get an Element. But it doesn't seem worth it to add
> an interface just for one method's worth of difference.
>

Sounds good.


On Mon, Feb 22, 2010 at 3:10 PM, Jonas Sicking <jonas at sicking.cc> wrote:

> What is the use case for this? It seems like in most cases you'll want
> to display something on screen to the user, and so the difference
> comes down to shipping drawing commands across the pipe, vs. shipping
> the pixel data.


Apologies for not including this at the start. As now mentioned in several
places in the thread, the simplest use case is resize/rotate of images.

However, more complex use cases may involve heavy users of canvas who would
like to either prerender the canvas and/or move the time taken to generate
the canvas off of the main thread. While it is true that simple uses of
canvas would not get a performance win out of this, if you are doing many
canvas operations, (like many complex operations) it is faster to copy a
result than it is to generate it.

Ideally canvas will get some form of toBlob which will allow the image to be
appropriately compressed as well which will also reduce the number of bits
that need to be copied from the worker to the main thread (as well as make
for a smaller upload than the raw bits).

Lastly, in the future, one can see other uses for the OffscreenCanvas
including WebGL for workers which several folks (Maciej and Jonas) have
expressed interest about on this thread.

dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100312/b4f6ec2e/attachment-0001.htm>