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

[Jonas Sicking]

On Fri, Mar 12, 2010 at 4:19 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> On Fri, Mar 12, 2010 at 3:38 PM, David Levin <levin at google.com> wrote:
>>
>>
>> On Fri, Mar 12, 2010 at 2:35 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>>>
>>> On Fri, Mar 12, 2010 at 12:46 PM, Oliver Hunt <oliver at apple.com> wrote:
>>> >
>>> > On Mar 12, 2010, at 12:16 PM, Jonas Sicking wrote:
>>> >> I'm not saying that the proposed API is bad. It just doesn't seem to
>>> >> solve the (seemingly most commonly requested) use case of
>>> >> rotating/scaling images. So if we want to solve those use cases we
>>> >> need to either come up with a separate API for that, or extend this
>>> >> proposal to solve that use case somehow.
>>> >
>>> > Just for reference I think one thing that people are forgetting that
>>> > there is a difference between
>>> > being computationally faster, and being more responsive.
>>>
>>> As I mentioned in my email, if you look at the steps listed, enough of
>>> them happen *on the main thread* that you're spending far more of the
>>> main threads CPU cycles than you'd like. Possibly even more than doing
>>> all the resizing on the main thread.
>>>
>>> With the other improvements suggested by David things do definitely
>>> look different, but those are not in a proposal yet.
>>
>> There is the other scenario I mentioned, but I'll see what I can do about
>> separately working up a proposal for adding those methods because they were
>> next on my list to deal with. (fromBlob/load may be enough for this.)
>
> Note that the other proposals that have been made has put toBlob on
> HTMLCanvasElement, not on the context. That makes the most sense for
> the main-thread canvas as that way its available on all contexts.

Oh, another thing to keep in mind is that if/when we add fromBlob to
the main-thread canvas, it has to be asynchronous in order to avoid
main thread synchronous IO. This isn't a big deal, but I figured I
should mention it while we're on the subject.

In general I wonder if we should add API to convert directly between
Blob and ImageData. Or at least Blob->ImageData and
ImageData->ByteArray. That could avoid overhead of going through a
canvas context. That is probably a win no matter which thread we are
on.

We could even add APIs to rotate and scale ImageData objects directly.
If those are asynchronous the implementation could easily implement
them using a background thread. I'm less sure that this is worth it
though given that you can implement this yourself using workers if we
add the other stuff we've talked about.

/ Jonas