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

On Mon, Feb 22, 2010 at 3:36 PM, David Levin <levin at google.com> wrote:
>
>
> On Mon, Feb 22, 2010 at 3:10 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>>
>> On Mon, Feb 22, 2010 at 11:13 AM, David Levin <levin at google.com> wrote:
>> > I've talked with some other folks on WebKit (Maciej and Oliver) about
>> > having
>> > a canvas that is available to workers. They suggested some nice
>> > modifications to make it an offscreen canvas, which may be used in the
>> > Document or in a Worker.
>>
>> 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.
>
>> The other use case I can think of is doing image manipulation and then
>> sending the result directly to the server, without ever displaying it
>> to the user. However this is first of all not supported by the
>> suggested API, and second I can't think of any image manipulation that
>> you wouldn't want to display to the user except for scaling down a
>> high resolution image. But that seems like a much simpler API than all
>> of canvas. And again, not even this simple use case is supported by
>> the current API.
>>
>
> A simple use case is image resizing which was what started the last thread
> and that is a similar use case to what I heard internally.
> I don't understand what you mean about things not being supported.
> 1. Given the current structure clone support, it is certainly possible to
> transfer image data to and from a worker, so it seems possible to display
> the result to the user. It is orthogonal to this feature but adding
> something like toFile (your proposal) and a corresponding fromFile/load
> would also aid in this (as well as aid in sending things to the server).
> 2. Resize may be done using the scale(x, y) method.

Ok, if you ship the data to the main thread you can do it. However
this means copying image in order to get it to the main thread which
seems pretty suboptimal.

And again, if this is the use case, then it seems like we could
construct a far simpler API.

/ Jonas

Received on Monday, 22 February 2010 15:53:44 UTC