On 3/20/2012 12:08 PM, Boris Zbarsky wrote:
On 3/20/12 3:00 PM, James Robinson wrote:
If we are adding new APIs for manipulating the backing directly, can we
make them asynchronous? This would allow for many optimization
opportunities that are currently difficult or impossible.
You mean like not blocking the world on the readback?
That would indeed be very nice. The question is what happens if
drawing happens after the getImageData call... Or for that matter
after the putImageData call (though I suspect there's less need for
putImageData to be async).
I recommend we complete+use RoC's media processing API in addition to
the CSS shaders proposal:
http://www.w3.org/TR/streamproc/
https://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html
This would allow async post-processing via workers and less worry about
putImage semantics.
If we're looking for async getImageData purely for recognition, I think
the current postMessage transfer semantics sped things up enough.
getImageData and a subsequent draw call are always going to need to grab
more memory. async isn't going to change that.
-Charles
