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
