[whatwg] Offscreen canvas (or canvas for web workers).
mjs at apple.com
Mon Mar 15 03:10:53 PDT 2010
On Mar 15, 2010, at 12:28 AM, Jonas Sicking wrote:
>> === Conclusions ===
>> 1) For scaling an image up 2x, copying to an ImageData and back for
>> processing on a Worker would improve responsiveness, relative to
>> just doing
>> the scale on the main thread.
>> 2) Copying from one canvas to another is much faster than copying
>> ImageData. To make copying to a Worker worthwhile as a responsiveness
>> improvement for rotations or downscales, in addition to the
>> proposal we would need a faster way to copy image data to a Worker.
>> possibility is to allow an OffscreenCanvas to be copied to and from a
>> background thread. It seems this would be much much faster than
>> copying via
> We're clearly going in circles here. My point is this:
> The two main use cases that has brought up have been scaling and
> rotating images off the main thread in order to improve
> responsiveness. The proposed solution addresses these use cases fairly
> poorly. Both in that APIs could be designed that makes these things
> simpler, and in that APIs could be designed that perform better both
> by putting less work on the main thread, and by doing less work in
Do you have a specific proposal for how to handle those particular use
cases? (Side note: I didn't test how efficient it would be to use
WebGL to scale or rotate images, in part because I'm not sure how to
do it. If you know how to code it, I'll gladly add it to my test case.)
BTW although no one has provided specific use cases along these lines,
I can imagine that Photoshop-style image processing effects may be
compute-intensive enough that you want to do them off the main thread.
At least, I think there's some photoshop filters that take noticeable
time to complete even as native-compiled C++. Maybe WebGL could be
used to do some or all of those things, it's hard to tell. It seems
like ImageData is *not* a great way to do them if you can help it,
since turning a large image into an ImageData is so expensive.
> This does not take away from the fact that the proposal can be (based
> on your data) be used to improve performance when doing scaling.
It looks to me like it could improve performance quite a lot if we add
a more efficient way
Actually, given that ImageData is already copiable to a background
thread, it seems like a good idea to add some form of image data that
can be copied to a Worker with less work on the main thread. That
seems valuable even if there is no actual graphics API on the
More information about the whatwg