W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2011

[whatwg] WebWorkers and images

From: Drew Wilson <atwilson@chromium.org>
Date: Fri, 7 Jan 2011 17:16:31 -0800
Message-ID: <AANLkTi=_kwLjXePHh_8d7oj3VnVUORO0vVF-xJ9z+Cvh@mail.gmail.com>
I would recommend that people review this thread:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-February/025254.htmlto
understand the objections previously raised to this idea.

-atw

On Fri, Jan 7, 2011 at 4:08 PM, Glenn Maynard <glenn at zewt.org> wrote:

> 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
>
Received on Friday, 7 January 2011 17:16:31 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:29 UTC