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

[Maciej Stachowiak]

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  
>> to/from
>> ImageData. To make copying to a Worker worthwhile as a responsiveness
>> improvement for rotations or downscales, in addition to the  
>> OffscreenCanvas
>> proposal we would need a faster way to copy image data to a Worker.  
>> One
>> 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
>> ImageData.
>
> 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
> general.

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  
background thread.

Regards,
Maciej