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

Jonas Sicking jonas at sicking.cc
Fri Mar 12 18:20:52 PST 2010

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

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

More information about the whatwg mailing list