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

[Oliver Hunt]

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.

If we imagine a scenario you're doing something that takes 100ms/frame, and it takes 10ms to
post the data between the main thread and a worker.

I _could_ do this all on the main thread in which case i have a fixed cost of a 100ms/frame, but
if I offload the processing to a worker my processing time per frame is now 120ms/frame.
The initial thought may be "ick slower" but the page is actually much more responsive -- when
processing on the main thread the main thread is blocked for 100ms at a time, whereas
processing on a worker means the main thread is not blocked for more than 10ms.  That's the
difference between being able to scroll in realtime vs. 10fps.

That also ignores the possibility of splitting the processing among multiple workers, once again
the total cpu time may increase, but the wall clock time can decrease dramatically.
> / Jonas
--Oliver