[whatwg] WebWorkers and images

[Glenn Maynard]

On Fri, Jan 7, 2011 at 6:22 PM, David Levin <levin at chromium.org> wrote:
> fwiw, ImageData can be used in a worker. Many folks have argued that canvas
> isn't that useful in a worker and that the gpu acceleration will make it
> less useful (and that most image manipulation would be able to use ImageData
> for its needs).

This is wrong.  You can't download, decompress and blit images to a
canvas in realtime from the main thread without causing UI hitches.

For example, if you load an HTMLImageElement to blit into a canvas,
image decompression often doesn't happen asynchronously during the
download, but synchronously when the image data is first used.  I
often see the UI freeze for 500-700ms to blit and scale a large image
in Chrome.  Implementations can alleviate this, but generally at a
cost elsewhere.  The real fix is to stop doing these expensive
operations from the UI thread--which is what threads are for.  GPU
acceleration won't magically fix every case where synchronous canvas
and canvas-related operations take too much time in the UI thread.

ImageData is only useful for a limited set of image operations.  For
image blitting and transformations--the most common canvas
operations--you need the canvas itself.  I'd suspect even more
important cases with WebGL; for example, long-running computations
using fragment shaders.

I understand why Canvas isn't available right now.  There are sticky
issues to make all of the parts practical to expose to threads, and
I'm sure getting the basic web workers API in place is much higher
priority.  But, I hope this will be revisited seriously at an
appropriate time, and not dismissed as not useful.  Image manipulation
is one of the most obvious candidates for threading.

-- 
Glenn Maynard